1. 18 Apr, 2017 1 commit
    • Herbert Xu's avatar
      af_key: Fix sadb_x_ipsecrequest parsing · 096f41d3
      Herbert Xu authored
      The parsing of sadb_x_ipsecrequest is broken in a number of ways.
      First of all we're not verifying sadb_x_ipsecrequest_len.  This
      is needed when the structure carries addresses at the end.  Worse
      we don't even look at the length when we parse those optional
      addresses.
      
      The migration code had similar parsing code that's better but
      it also has some deficiencies.  The length is overcounted first
      of all as it includes the header itself.  It also fails to check
      the length before dereferencing the sa_family field.
      
      This patch fixes those problems in parse_sockaddr_pair and then
      uses it in parse_ipsecrequest.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      096f41d3
  2. 03 Apr, 2017 2 commits
  3. 02 Apr, 2017 7 commits
    • David S. Miller's avatar
      Merge branch 'l2tp_session_find-fixes' · e5c1e519
      David S. Miller authored
      Guillaume Nault says:
      
      ====================
      l2tp: fix usage of l2tp_session_find()
      
      l2tp_session_find() doesn't take a reference on the session returned to
      its caller. Virtually all l2tp_session_find() users are racy, either
      because the session can disappear from under them or because they take
      a reference too late. This leads to bugs like 'use after free' or
      failure to notice duplicate session creations.
      
      In some cases, taking a reference on the session is not enough. The
      special callbacks .ref() and .deref() also have to be called in cases
      where the PPP pseudo-wire uses the socket associated with the session.
      Therefore, when looking up a session, we also have to pass a flag
      indicating if the .ref() callback has to be called.
      
      In the future, we probably could drop the .ref() and .deref() callbacks
      entirely by protecting the .sock field of struct pppol2tp_session with
      RCU, thus allowing it to be freed and set to NULL even if the L2TP
      session is still alive.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e5c1e519
    • Guillaume Nault's avatar
      l2tp: take a reference on sessions used in genetlink handlers · 2777e2ab
      Guillaume Nault authored
      Callers of l2tp_nl_session_find() need to hold a reference on the
      returned session since there's no guarantee that it isn't going to
      disappear from under them.
      
      Relying on the fact that no l2tp netlink message may be processed
      concurrently isn't enough: sessions can be deleted by other means
      (e.g. by closing the PPPOL2TP socket of a ppp pseudowire).
      
      l2tp_nl_cmd_session_delete() is a bit special: it runs a callback
      function that may require a previous call to session->ref(). In
      particular, for ppp pseudowires, the callback is l2tp_session_delete(),
      which then calls pppol2tp_session_close() and dereferences the PPPOL2TP
      socket. The socket might already be gone at the moment
      l2tp_session_delete() calls session->ref(), so we need to take a
      reference during the session lookup. So we need to pass the do_ref
      variable down to l2tp_session_get() and l2tp_session_get_by_ifname().
      
      Since all callers have to be updated, l2tp_session_find_by_ifname() and
      l2tp_nl_session_find() are renamed to reflect their new behaviour.
      
      Fixes: 309795f4 ("l2tp: Add netlink control API for L2TP")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2777e2ab
    • Guillaume Nault's avatar
      l2tp: hold session while sending creation notifications · 5e6a9e5a
      Guillaume Nault authored
      l2tp_session_find() doesn't take any reference on the returned session.
      Therefore, the session may disappear while sending the notification.
      
      Use l2tp_session_get() instead and decrement session's refcount once
      the notification is sent.
      
      Fixes: 33f72e6f ("l2tp : multicast notification to the registered listeners")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e6a9e5a
    • Guillaume Nault's avatar
      l2tp: fix duplicate session creation · dbdbc73b
      Guillaume Nault authored
      l2tp_session_create() relies on its caller for checking for duplicate
      sessions. This is racy since a session can be concurrently inserted
      after the caller's verification.
      
      Fix this by letting l2tp_session_create() verify sessions uniqueness
      upon insertion. Callers need to be adapted to check for
      l2tp_session_create()'s return code instead of calling
      l2tp_session_find().
      
      pppol2tp_connect() is a bit special because it has to work on existing
      sessions (if they're not connected) or to create a new session if none
      is found. When acting on a preexisting session, a reference must be
      held or it could go away on us. So we have to use l2tp_session_get()
      instead of l2tp_session_find() and drop the reference before exiting.
      
      Fixes: d9e31d17 ("l2tp: Add L2TP ethernet pseudowire support")
      Fixes: fd558d18 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dbdbc73b
    • Guillaume Nault's avatar
      l2tp: ensure session can't get removed during pppol2tp_session_ioctl() · 57377d63
      Guillaume Nault authored
      Holding a reference on session is required before calling
      pppol2tp_session_ioctl(). The session could get freed while processing the
      ioctl otherwise. Since pppol2tp_session_ioctl() uses the session's socket,
      we also need to take a reference on it in l2tp_session_get().
      
      Fixes: fd558d18 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      57377d63
    • Guillaume Nault's avatar
      l2tp: fix race in l2tp_recv_common() · 61b9a047
      Guillaume Nault authored
      Taking a reference on sessions in l2tp_recv_common() is racy; this
      has to be done by the callers.
      
      To this end, a new function is required (l2tp_session_get()) to
      atomically lookup a session and take a reference on it. Callers then
      have to manually drop this reference.
      
      Fixes: fd558d18 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61b9a047
    • Xin Long's avatar
      sctp: use right in and out stream cnt · afe89962
      Xin Long authored
      Since sctp reconf was added in sctp, the real cnt of in/out stream
      have not been c.sinit_max_instreams and c.sinit_num_ostreams any
      more.
      
      This patch is to replace them with stream->in/outcnt.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      afe89962
  4. 01 Apr, 2017 9 commits
    • David S. Miller's avatar
      Merge tag 'mac80211-for-davem-2017-03-31' of... · 612307c6
      David S. Miller authored
      Merge tag 'mac80211-for-davem-2017-03-31' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      Two fixes:
       * don't block netdev queues (indefinitely!) if mac80211
         manages traffic queueing itself
       * check wiphy registration before checking for ops
         on resume, to avoid crash
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      612307c6
    • David S. Miller's avatar
      Merge branch 'bpf-map_value_adj-reg-types-fixes' · 0989bd03
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      BPF fixes on map_value_adj reg types
      
      This set adds two fixes for map_value_adj register type in the
      verifier and user space tests along with them for the BPF self
      test suite. For details, please see individual patches.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0989bd03
    • Daniel Borkmann's avatar
      bpf: add various verifier test cases for self-tests · 02ea80b1
      Daniel Borkmann authored
      Add a couple of test cases, for example, probing for xadd on a spilled
      pointer to packet and map_value_adj register, various other map_value_adj
      tests including the unaligned load/store, and trying out pointer arithmetic
      on map_value_adj register itself. For the unaligned load/store, we need
      to figure out whether the architecture has efficient unaligned access and
      need to mark affected tests accordingly.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      02ea80b1
    • Daniel Borkmann's avatar
      bpf, verifier: fix rejection of unaligned access checks for map_value_adj · 79adffcd
      Daniel Borkmann authored
      Currently, the verifier doesn't reject unaligned access for map_value_adj
      register types. Commit 48461135 ("bpf: allow access into map value
      arrays") added logic to check_ptr_alignment() extending it from PTR_TO_PACKET
      to also PTR_TO_MAP_VALUE_ADJ, but for PTR_TO_MAP_VALUE_ADJ no enforcement
      is in place, because reg->id for PTR_TO_MAP_VALUE_ADJ reg types is never
      non-zero, meaning, we can cause BPF_H/_W/_DW-based unaligned access for
      architectures not supporting efficient unaligned access, and thus worst
      case could raise exceptions on some archs that are unable to correct the
      unaligned access or perform a different memory access to the actual
      requested one and such.
      
      i) Unaligned load with !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
         on r0 (map_value_adj):
      
         0: (bf) r2 = r10
         1: (07) r2 += -8
         2: (7a) *(u64 *)(r2 +0) = 0
         3: (18) r1 = 0x42533a00
         5: (85) call bpf_map_lookup_elem#1
         6: (15) if r0 == 0x0 goto pc+11
          R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp
         7: (61) r1 = *(u32 *)(r0 +0)
         8: (35) if r1 >= 0xb goto pc+9
          R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R1=inv,min_value=0,max_value=10 R10=fp
         9: (07) r0 += 3
        10: (79) r7 = *(u64 *)(r0 +0)
          R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R1=inv,min_value=0,max_value=10 R10=fp
        11: (79) r7 = *(u64 *)(r0 +2)
          R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R1=inv,min_value=0,max_value=10 R7=inv R10=fp
        [...]
      
      ii) Unaligned store with !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
          on r0 (map_value_adj):
      
         0: (bf) r2 = r10
         1: (07) r2 += -8
         2: (7a) *(u64 *)(r2 +0) = 0
         3: (18) r1 = 0x4df16a00
         5: (85) call bpf_map_lookup_elem#1
         6: (15) if r0 == 0x0 goto pc+19
          R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp
         7: (07) r0 += 3
         8: (7a) *(u64 *)(r0 +0) = 42
          R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R10=fp
         9: (7a) *(u64 *)(r0 +2) = 43
          R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R10=fp
        10: (7a) *(u64 *)(r0 -2) = 44
          R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R10=fp
        [...]
      
      For the PTR_TO_PACKET type, reg->id is initially zero when skb->data
      was fetched, it later receives a reg->id from env->id_gen generator
      once another register with UNKNOWN_VALUE type was added to it via
      check_packet_ptr_add(). The purpose of this reg->id is twofold: i) it
      is used in find_good_pkt_pointers() for setting the allowed access
      range for regs with PTR_TO_PACKET of same id once verifier matched
      on data/data_end tests, and ii) for check_ptr_alignment() to determine
      that when not having efficient unaligned access and register with
      UNKNOWN_VALUE was added to PTR_TO_PACKET, that we're only allowed
      to access the content bytewise due to unknown unalignment. reg->id
      was never intended for PTR_TO_MAP_VALUE{,_ADJ} types and thus is
      always zero, the only marking is in PTR_TO_MAP_VALUE_OR_NULL that
      was added after 48461135 via 57a09bf0 ("bpf: Detect identical
      PTR_TO_MAP_VALUE_OR_NULL registers"). Above tests will fail for
      non-root environment due to prohibited pointer arithmetic.
      
      The fix splits register-type specific checks into their own helper
      instead of keeping them combined, so we don't run into a similar
      issue in future once we extend check_ptr_alignment() further and
      forget to add reg->type checks for some of the checks.
      
      Fixes: 48461135 ("bpf: allow access into map value arrays")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarJosef Bacik <jbacik@fb.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      79adffcd
    • Daniel Borkmann's avatar
      bpf, verifier: fix alu ops against map_value{, _adj} register types · fce366a9
      Daniel Borkmann authored
      While looking into map_value_adj, I noticed that alu operations
      directly on the map_value() resp. map_value_adj() register (any
      alu operation on a map_value() register will turn it into a
      map_value_adj() typed register) are not sufficiently protected
      against some of the operations. Two non-exhaustive examples are
      provided that the verifier needs to reject:
      
       i) BPF_AND on r0 (map_value_adj):
      
        0: (bf) r2 = r10
        1: (07) r2 += -8
        2: (7a) *(u64 *)(r2 +0) = 0
        3: (18) r1 = 0xbf842a00
        5: (85) call bpf_map_lookup_elem#1
        6: (15) if r0 == 0x0 goto pc+2
         R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp
        7: (57) r0 &= 8
        8: (7a) *(u64 *)(r0 +0) = 22
         R0=map_value_adj(ks=8,vs=48,id=0),min_value=0,max_value=8 R10=fp
        9: (95) exit
      
        from 6 to 9: R0=inv,min_value=0,max_value=0 R10=fp
        9: (95) exit
        processed 10 insns
      
      ii) BPF_ADD in 32 bit mode on r0 (map_value_adj):
      
        0: (bf) r2 = r10
        1: (07) r2 += -8
        2: (7a) *(u64 *)(r2 +0) = 0
        3: (18) r1 = 0xc24eee00
        5: (85) call bpf_map_lookup_elem#1
        6: (15) if r0 == 0x0 goto pc+2
         R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp
        7: (04) (u32) r0 += (u32) 0
        8: (7a) *(u64 *)(r0 +0) = 22
         R0=map_value_adj(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp
        9: (95) exit
      
        from 6 to 9: R0=inv,min_value=0,max_value=0 R10=fp
        9: (95) exit
        processed 10 insns
      
      Issue is, while min_value / max_value boundaries for the access
      are adjusted appropriately, we change the pointer value in a way
      that cannot be sufficiently tracked anymore from its origin.
      Operations like BPF_{AND,OR,DIV,MUL,etc} on a destination register
      that is PTR_TO_MAP_VALUE{,_ADJ} was probably unintended, in fact,
      all the test cases coming with 48461135 ("bpf: allow access
      into map value arrays") perform BPF_ADD only on the destination
      register that is PTR_TO_MAP_VALUE_ADJ.
      
      Only for UNKNOWN_VALUE register types such operations make sense,
      f.e. with unknown memory content fetched initially from a constant
      offset from the map value memory into a register. That register is
      then later tested against lower / upper bounds, so that the verifier
      can then do the tracking of min_value / max_value, and properly
      check once that UNKNOWN_VALUE register is added to the destination
      register with type PTR_TO_MAP_VALUE{,_ADJ}. This is also what the
      original use-case is solving. Note, tracking on what is being
      added is done through adjust_reg_min_max_vals() and later access
      to the map value enforced with these boundaries and the given offset
      from the insn through check_map_access_adj().
      
      Tests will fail for non-root environment due to prohibited pointer
      arithmetic, in particular in check_alu_op(), we bail out on the
      is_pointer_value() check on the dst_reg (which is false in root
      case as we allow for pointer arithmetic via env->allow_ptr_leaks).
      
      Similarly to PTR_TO_PACKET, one way to fix it is to restrict the
      allowed operations on PTR_TO_MAP_VALUE{,_ADJ} registers to 64 bit
      mode BPF_ADD. The test_verifier suite runs fine after the patch
      and it also rejects mentioned test cases.
      
      Fixes: 48461135 ("bpf: allow access into map value arrays")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarJosef Bacik <jbacik@fb.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fce366a9
    • René Rebe's avatar
      r8152: The Microsoft Surface docks also use R8152 v2 · d5b07ccc
      René Rebe authored
      Without this the generic cdc_ether grabs the device,
      and does not really work.
      Signed-off-by: default avatarRené Rebe <rene@exactcode.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d5b07ccc
    • Yi-Hung Wei's avatar
      openvswitch: Fix ovs_flow_key_update() · 6f56f618
      Yi-Hung Wei authored
      ovs_flow_key_update() is called when the flow key is invalid, and it is
      used to update and revalidate the flow key. Commit 329f45bc
      ("openvswitch: add mac_proto field to the flow key") introduces mac_proto
      field to flow key and use it to determine whether the flow key is valid.
      However, the commit does not update the code path in ovs_flow_key_update()
      to revalidate the flow key which may cause BUG_ON() on execute_recirc().
      This patch addresses the aforementioned issue.
      
      Fixes: 329f45bc ("openvswitch: add mac_proto field to the flow key")
      Signed-off-by: default avatarYi-Hung Wei <yihung.wei@gmail.com>
      Acked-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f56f618
    • Mark Brown's avatar
      net/faraday: Explicitly include linux/of.h and linux/property.h · 3af887c3
      Mark Brown authored
      This driver uses interfaces from linux/of.h and linux/property.h but
      relies on implict inclusion of those headers which means that changes in
      other headers could break the build, as happened in -next for arm today.
      Add a explicit includes.
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Acked-by: default avatarJoel Stanley <joel@jms.id.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3af887c3
    • Daode Huang's avatar
      net: hns: Add ACPI support to check SFP present · b917078c
      Daode Huang authored
      The current code only supports DT to check SFP present.
      This patch adds ACPI support as well.
      Signed-off-by: default avatarDaode Huang <huangdaode@hisilicon.com>
      Reviewed-by: default avatarYisen Zhuang <yisen.zhuang@huawei.com>
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b917078c
  5. 30 Mar, 2017 5 commits
  6. 29 Mar, 2017 16 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 8f1f7eeb
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains a rather large update with Netfilter
      fixes, specifically targeted to incorrect RCU usage in several spots and
      the userspace conntrack helper infrastructure (nfnetlink_cthelper),
      more specifically they are:
      
      1) expect_class_max is incorrect set via cthelper, as in kernel semantics
         mandate that this represents the array of expectation classes minus 1.
         Patch from Liping Zhang.
      
      2) Expectation policy updates via cthelper are currently broken for several
         reasons: This code allows illegal changes in the policy such as changing
         the number of expeciation classes, it is leaking the updated policy and
         such update occurs with no RCU protection at all. Fix this by adding a
         new nfnl_cthelper_update_policy() that describes what is really legal on
         the update path.
      
      3) Fix several memory leaks in cthelper, from Jeffy Chen.
      
      4) synchronize_rcu() is missing in the removal path of several modules,
         this may lead to races since CPU may still be running on code that has
         just gone. Also from Liping Zhang.
      
      5) Don't use the helper hashtable from cthelper, it is not safe to walk
         over those bits without the helper mutex. Fix this by introducing a
         new independent list for userspace helpers. From Liping Zhang.
      
      6) nf_ct_extend_unregister() needs synchronize_rcu() to make sure no
         packets are walking on any conntrack extension that is gone after
         module removal, again from Liping.
      
      7) nf_nat_snmp may crash if we fail to unregister the helper due to
         accidental leftover code, from Gao Feng.
      
      8) Fix leak in nfnetlink_queue with secctx support, from Liping Zhang.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f1f7eeb
    • Zakharov Vlad's avatar
      ezchip: nps_enet: check if napi has been completed · 358e78b5
      Zakharov Vlad authored
      After a new NAPI_STATE_MISSED state was added to NAPI we can get into
      this state and in such case we have to reschedule NAPI as some work is
      still pending and we have to process it. napi_complete_done() function
      returns false if we have to reschedule something (e.g. in case we were
      in MISSED state) as current polling have not been completed yet.
      
      nps_enet driver hasn't been verifying the return value of
      napi_complete_done() and has been forcibly enabling interrupts. That is
      not correct as we should not enable interrupts before we have processed
      all scheduled work. As a result we were getting trapped in interrupt
      hanlder chain as we had never been able to disabale ethernet
      interrupts again.
      
      So this patch makes nps_enet_poll() func verify return value of
      napi_complete_done() and enable interrupts only in case all scheduled
      work has been completed.
      Signed-off-by: default avatarVlad Zakharov <vzakhar@synopsys.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      358e78b5
    • David S. Miller's avatar
      Merge branch 'bnxt_en-fixes' · a1801cc8
      David S. Miller authored
      Michael Chan says:
      
      ====================
      bnxt_en: Small misc. fixes.
      
      Fix a NULL pointer crash in open failure path, wrong arguments when
      printing error messages, and a DMA unmap bug in XDP shutdown path.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a1801cc8
    • Michael Chan's avatar
      bnxt_en: Fix DMA unmapping of the RX buffers in XDP mode during shutdown. · 3ed3a83e
      Michael Chan authored
      In bnxt_free_rx_skbs(), which is called to free up all RX buffers during
      shutdown, we need to unmap the page if we are running in XDP mode.
      
      Fixes: c61fb99c ("bnxt_en: Add RX page mode support.")
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ed3a83e
    • Sankar Patchineelam's avatar
    • Sankar Patchineelam's avatar
      bnxt_en: Fix NULL pointer dereference in reopen failure path · 2247925f
      Sankar Patchineelam authored
      Net device reset can fail when the h/w or f/w is in a bad state.
      Subsequent netdevice open fails in bnxt_hwrm_stat_ctx_alloc().
      The cleanup invokes bnxt_hwrm_resource_free() which inturn
      calls bnxt_disable_int().  In this routine, the code segment
      
      if (ring->fw_ring_id != INVALID_HW_RING_ID)
         BNXT_CP_DB(cpr->cp_doorbell, cpr->cp_raw_cons);
      
      results in NULL pointer dereference as cpr->cp_doorbell is not yet
      initialized, and fw_ring_id is zero.
      
      The fix is to initialize cpr fw_ring_id to INVALID_HW_RING_ID before
      bnxt_init_chip() is invoked.
      Signed-off-by: default avatarSankar Patchineelam <sankar.patchineelam@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2247925f
    • Guillaume Nault's avatar
      l2tp: purge socket queues in the .destruct() callback · e91793bb
      Guillaume Nault authored
      The Rx path may grab the socket right before pppol2tp_release(), but
      nothing guarantees that it will enqueue packets before
      skb_queue_purge(). Therefore, the socket can be destroyed without its
      queues fully purged.
      
      Fix this by purging queues in pppol2tp_session_destruct() where we're
      guaranteed nothing is still referencing the socket.
      
      Fixes: 9e9cb622 ("l2tp: fix userspace reception on plain L2TP sockets")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e91793bb
    • Guillaume Nault's avatar
      l2tp: hold tunnel socket when handling control frames in l2tp_ip and l2tp_ip6 · 94d7ee0b
      Guillaume Nault authored
      The code following l2tp_tunnel_find() expects that a new reference is
      held on sk. Either sk_receive_skb() or the discard_put error path will
      drop a reference from the tunnel's socket.
      
      This issue exists in both l2tp_ip and l2tp_ip6.
      
      Fixes: a3c18422 ("l2tp: hold socket before dropping lock in l2tp_ip{, 6}_recv()")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      94d7ee0b
    • Johannes Berg's avatar
      mac80211: unconditionally start new netdev queues with iTXQ support · 7d65f829
      Johannes Berg authored
      When internal mac80211 TXQs aren't supported, netdev queues must
      always started out started even when driver queues are stopped
      while the interface is added. This is necessary because with the
      internal TXQ support netdev queues are never stopped and packet
      scheduling/dropping is done in mac80211.
      
      Cc: stable@vger.kernel.org # 4.9+
      Fixes: 80a83cfc ("mac80211: skip netdev queue control with software queuing")
      Reported-and-tested-by: default avatarSven Eckelmann <sven.eckelmann@openmesh.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      7d65f829
    • Liping Zhang's avatar
      netfilter: nfnetlink_queue: fix secctx memory leak · 77c1c03c
      Liping Zhang authored
      We must call security_release_secctx to free the memory returned by
      security_secid_to_secctx, otherwise memory may be leaked forever.
      
      Fixes: ef493bd9 ("netfilter: nfnetlink_queue: add security context information")
      Signed-off-by: default avatarLiping Zhang <zlpnobody@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      77c1c03c
    • Arend Van Spriel's avatar
      cfg80211: check rdev resume callback only for registered wiphy · b3ef5520
      Arend Van Spriel authored
      We got the following use-after-free KASAN report:
      
       BUG: KASAN: use-after-free in wiphy_resume+0x591/0x5a0 [cfg80211]
      	 at addr ffff8803fc244090
       Read of size 8 by task kworker/u16:24/2587
       CPU: 6 PID: 2587 Comm: kworker/u16:24 Tainted: G    B 4.9.13-debug+
       Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 1.2.19 12/22/2016
       Workqueue: events_unbound async_run_entry_fn
        ffff880425d4f9d8 ffffffffaeedb541 ffff88042b80ef00 ffff8803fc244088
        ffff880425d4fa00 ffffffffae84d7a1 ffff880425d4fa98 ffff8803fc244080
        ffff88042b80ef00 ffff880425d4fa88 ffffffffae84da3a ffffffffc141f7d9
       Call Trace:
        [<ffffffffaeedb541>] dump_stack+0x85/0xc4
        [<ffffffffae84d7a1>] kasan_object_err+0x21/0x70
        [<ffffffffae84da3a>] kasan_report_error+0x1fa/0x500
        [<ffffffffc141f7d9>] ? cfg80211_bss_age+0x39/0xc0 [cfg80211]
        [<ffffffffc141f83a>] ? cfg80211_bss_age+0x9a/0xc0 [cfg80211]
        [<ffffffffae48d46d>] ? trace_hardirqs_on+0xd/0x10
        [<ffffffffc13fb1c0>] ? wiphy_suspend+0xc70/0xc70 [cfg80211]
        [<ffffffffae84def1>] __asan_report_load8_noabort+0x61/0x70
        [<ffffffffc13fb100>] ? wiphy_suspend+0xbb0/0xc70 [cfg80211]
        [<ffffffffc13fb751>] ? wiphy_resume+0x591/0x5a0 [cfg80211]
        [<ffffffffc13fb751>] wiphy_resume+0x591/0x5a0 [cfg80211]
        [<ffffffffc13fb1c0>] ? wiphy_suspend+0xc70/0xc70 [cfg80211]
        [<ffffffffaf3b206e>] dpm_run_callback+0x6e/0x4f0
        [<ffffffffaf3b31b2>] device_resume+0x1c2/0x670
        [<ffffffffaf3b367d>] async_resume+0x1d/0x50
        [<ffffffffae3ee84e>] async_run_entry_fn+0xfe/0x610
        [<ffffffffae3d0666>] process_one_work+0x716/0x1a50
        [<ffffffffae3d05c9>] ? process_one_work+0x679/0x1a50
        [<ffffffffafdd7b6d>] ? _raw_spin_unlock_irq+0x3d/0x60
        [<ffffffffae3cff50>] ? pwq_dec_nr_in_flight+0x2b0/0x2b0
        [<ffffffffae3d1a80>] worker_thread+0xe0/0x1460
        [<ffffffffae3d19a0>] ? process_one_work+0x1a50/0x1a50
        [<ffffffffae3e54c2>] kthread+0x222/0x2e0
        [<ffffffffae3e52a0>] ? kthread_park+0x80/0x80
        [<ffffffffae3e52a0>] ? kthread_park+0x80/0x80
        [<ffffffffae3e52a0>] ? kthread_park+0x80/0x80
        [<ffffffffafdd86aa>] ret_from_fork+0x2a/0x40
       Object at ffff8803fc244088, in cache kmalloc-1024 size: 1024
       Allocated:
       PID = 71
        save_stack_trace+0x1b/0x20
        save_stack+0x46/0xd0
        kasan_kmalloc+0xad/0xe0
        kasan_slab_alloc+0x12/0x20
        __kmalloc_track_caller+0x134/0x360
        kmemdup+0x20/0x50
        brcmf_cfg80211_attach+0x10b/0x3a90 [brcmfmac]
        brcmf_bus_start+0x19a/0x9a0 [brcmfmac]
        brcmf_pcie_setup+0x1f1a/0x3680 [brcmfmac]
        brcmf_fw_request_nvram_done+0x44c/0x11b0 [brcmfmac]
        request_firmware_work_func+0x135/0x280
        process_one_work+0x716/0x1a50
        worker_thread+0xe0/0x1460
        kthread+0x222/0x2e0
        ret_from_fork+0x2a/0x40
       Freed:
       PID = 2568
        save_stack_trace+0x1b/0x20
        save_stack+0x46/0xd0
        kasan_slab_free+0x71/0xb0
        kfree+0xe8/0x2e0
        brcmf_cfg80211_detach+0x62/0xf0 [brcmfmac]
        brcmf_detach+0x14a/0x2b0 [brcmfmac]
        brcmf_pcie_remove+0x140/0x5d0 [brcmfmac]
        brcmf_pcie_pm_leave_D3+0x198/0x2e0 [brcmfmac]
        pci_pm_resume+0x186/0x220
        dpm_run_callback+0x6e/0x4f0
        device_resume+0x1c2/0x670
        async_resume+0x1d/0x50
        async_run_entry_fn+0xfe/0x610
        process_one_work+0x716/0x1a50
        worker_thread+0xe0/0x1460
        kthread+0x222/0x2e0
        ret_from_fork+0x2a/0x40
       Memory state around the buggy address:
        ffff8803fc243f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffff8803fc244000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       >ffff8803fc244080: fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                ^
        ffff8803fc244100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff8803fc244180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      What is happening is that brcmf_pcie_resume() detects a device that
      is no longer responsive and it decides to unbind resulting in a
      wiphy_unregister() and wiphy_free() call. Now the wiphy instance
      remains allocated, because PM needs to call wiphy_resume() for it.
      However, brcmfmac already does a kfree() for the struct
      cfg80211_registered_device::ops field. Change the checks in
      wiphy_resume() to only access the struct cfg80211_registered_device::ops
      if the wiphy instance is still registered at this time.
      
      Cc: stable@vger.kernel.org # 4.10.x, 4.9.x
      Reported-by: default avatarDaniel J Blueman <daniel@quora.org>
      Reviewed-by: default avatarHante Meuleman <hante.meuleman@broadcom.com>
      Reviewed-by: default avatarPieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
      Reviewed-by: default avatarFranky Lin <franky.lin@broadcom.com>
      Signed-off-by: default avatarArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b3ef5520
    • Jarno Rajahalme's avatar
      openvswitch: Fix refcount leak on force commit. · b768b16d
      Jarno Rajahalme authored
      The reference count held for skb needs to be released when the skb's
      nfct pointer is cleared regardless of if nf_ct_delete() is called or
      not.
      
      Failing to release the skb's reference cound led to deferred conntrack
      cleanup spinning forever within nf_conntrack_cleanup_net_list() when
      cleaning up a network namespace:
      
         kworker/u16:0-19025 [004] 45981067.173642: sched_switch: kworker/u16:0:19025 [120] R ==> rcu_preempt:7 [120]
         kworker/u16:0-19025 [004] 45981067.173651: kernel_stack: <stack trace>
      => ___preempt_schedule (ffffffffa001ed36)
      => _raw_spin_unlock_bh (ffffffffa0713290)
      => nf_ct_iterate_cleanup (ffffffffc00a4454)
      => nf_conntrack_cleanup_net_list (ffffffffc00a5e1e)
      => nf_conntrack_pernet_exit (ffffffffc00a63dd)
      => ops_exit_list.isra.1 (ffffffffa06075f3)
      => cleanup_net (ffffffffa0607df0)
      => process_one_work (ffffffffa0084c31)
      => worker_thread (ffffffffa008592b)
      => kthread (ffffffffa008bee2)
      => ret_from_fork (ffffffffa071b67c)
      
      Fixes: dd41d33f ("openvswitch: Add force commit.")
      Reported-by: default avatarYang Song <yangsong@vmware.com>
      Signed-off-by: default avatarJarno Rajahalme <jarno@ovn.org>
      Acked-by: default avatarJoe Stringer <joe@ovn.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b768b16d
    • Arnd Bergmann's avatar
      rocker: fix Wmaybe-uninitialized false-positive · 16b8b6de
      Arnd Bergmann authored
      gcc-7 reports a warning that earlier versions did not have:
      
      drivers/net/ethernet/rocker/rocker_ofdpa.c: In function 'ofdpa_port_stp_update':
      arch/x86/include/asm/string_32.h:79:22: error: '*((void *)&prev_ctrls+4)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         *((short *)to + 2) = *((short *)from + 2);
         ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
      drivers/net/ethernet/rocker/rocker_ofdpa.c:2218:7: note: '*((void *)&prev_ctrls+4)' was declared here
      
      This is clearly a variation of the warning about 'prev_state' that
      was shut up using uninitialized_var().
      
      We can slightly simplify the code and get rid of the warning by unconditionally
      saving the prev_state and prev_ctrls variables. The inlined memcpy is not
      particularly expensive here, as it just has to read five bytes from one or
      two cache lines.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16b8b6de
    • Talat Batheesh's avatar
      net/mlx5: Avoid dereferencing uninitialized pointer · e497ec68
      Talat Batheesh authored
      In NETDEV_CHANGEUPPER event the upper_info field is valid
      only when linking is true. Otherwise it should be ignored.
      
      Fixes: 7907f23a (net/mlx5: Implement RoCE LAG feature)
      Signed-off-by: default avatarTalat Batheesh <talatb@mellanox.com>
      Reviewed-by: default avatarAviv Heller <avivh@mellanox.com>
      Reviewed-by: default avatarMoni Shoua <monis@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e497ec68
    • Jonas Jensen's avatar
      net: moxa: fix TX overrun memory leak · c2b341a6
      Jonas Jensen authored
      moxart_mac_start_xmit() doesn't care where tx_tail is, tx_head can
      catch and pass tx_tail, which is bad because moxart_tx_finished()
      isn't guaranteed to catch up on freeing resources from tx_tail.
      
      Add a check in moxart_mac_start_xmit() stopping the queue at the
      end of the circular buffer. Also add a check in moxart_tx_finished()
      waking the queue if the buffer has TX_WAKE_THRESHOLD or more
      free descriptors.
      
      While we're at it, move spin_lock_irq() to happen before our
      descriptor pointer is assigned in moxart_mac_start_xmit().
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=99451Signed-off-by: default avatarJonas Jensen <jonas.jensen@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c2b341a6
    • Arnd Bergmann's avatar
      isdn: kcapi: avoid uninitialized data · af109a2c
      Arnd Bergmann authored
      gcc-7 points out that the AVMB1_ADDCARD ioctl results in an unintialized
      value ending up in the cardnr parameter:
      
      drivers/isdn/capi/kcapi.c: In function 'old_capi_manufacturer':
      drivers/isdn/capi/kcapi.c:1042:24: error: 'cdef.cardnr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         cparams.cardnr = cdef.cardnr;
      
      This has been broken since before the start of the git history, so
      either the value is not used for anything important, or the ioctl
      command doesn't get called in practice.
      
      Setting the cardnr to zero avoids the warning and makes sure
      we have consistent behavior.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      af109a2c