1. 20 Dec, 2019 7 commits
    • David Howells's avatar
      rxrpc: Fix missing security check on incoming calls · 063c60d3
      David Howells authored
      Fix rxrpc_new_incoming_call() to check that we have a suitable service key
      available for the combination of service ID and security class of a new
      incoming call - and to reject calls for which we don't.
      
      This causes an assertion like the following to appear:
      
      	rxrpc: Assertion failed - 6(0x6) == 12(0xc) is false
      	kernel BUG at net/rxrpc/call_object.c:456!
      
      Where call->state is RXRPC_CALL_SERVER_SECURING (6) rather than
      RXRPC_CALL_COMPLETE (12).
      
      Fixes: 248f219c ("rxrpc: Rewrite the data and ack handling code")
      Reported-by: default avatarMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      063c60d3
    • David Howells's avatar
      rxrpc: Don't take call->user_mutex in rxrpc_new_incoming_call() · 13b7955a
      David Howells authored
      Standard kernel mutexes cannot be used in any way from interrupt or softirq
      context, so the user_mutex which manages access to a call cannot be a mutex
      since on a new call the mutex must start off locked and be unlocked within
      the softirq handler to prevent userspace interfering with a call we're
      setting up.
      
      Commit a0855d24 ("locking/mutex: Complain
      upon mutex API misuse in IRQ contexts") causes big warnings to be splashed
      in dmesg for each a new call that comes in from the server.  Whilst it
      *seems* like it should be okay, since the accept path uses trylock, there
      are issues with PI boosting and marking the wrong task as the owner.
      
      Fix this by not taking the mutex in the softirq path at all.  It's not
      obvious that there should be any need for it as the state is set before the
      first notification is generated for the new call.
      
      There's also no particular reason why the link-assessing ping should be
      triggered inside the mutex.  It's not actually transmitted there anyway,
      but rather it has to be deferred to a workqueue.
      
      Further, I don't think that there's any particular reason that the socket
      notification needs to be done from within rx->incoming_lock, so the amount
      of time that lock is held can be shortened too and the ping prepared before
      the new call notification is sent.
      
      Fixes: 540b1c48 ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      cc: Ingo Molnar <mingo@redhat.com>
      cc: Will Deacon <will@kernel.org>
      cc: Davidlohr Bueso <dave@stgolabs.net>
      13b7955a
    • David Howells's avatar
      rxrpc: Unlock new call in rxrpc_new_incoming_call() rather than the caller · f33121cb
      David Howells authored
      Move the unlock and the ping transmission for a new incoming call into
      rxrpc_new_incoming_call() rather than doing it in the caller.  This makes
      it clearer to see what's going on.
      Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      cc: Ingo Molnar <mingo@redhat.com>
      cc: Will Deacon <will@kernel.org>
      cc: Davidlohr Bueso <dave@stgolabs.net>
      f33121cb
    • Aditya Pakki's avatar
      nfc: s3fwrn5: replace the assertion with a WARN_ON · 615f22f5
      Aditya Pakki authored
      In s3fwrn5_fw_recv_frame, if fw_info->rsp is not empty, the
      current code causes a crash via BUG_ON. However, s3fwrn5_fw_send_msg
      does not crash in such a scenario. The patch replaces the BUG_ON
      by returning the error to the callers and frees up skb.
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      615f22f5
    • David S. Miller's avatar
      Merge branch 'macb-fix-probing-of-PHY-not-described-in-the-dt' · a019739c
      David S. Miller authored
      Antoine Tenart says:
      
      ====================
      net: macb: fix probing of PHY not described in the dt
      
      The macb Ethernet driver supports various ways of referencing its
      network PHY. When a device tree is used the PHY can be referenced with
      a phy-handle or, if connected to its internal MDIO bus, described in
      a child node. Some platforms omitted the PHY description while
      connecting the PHY to the internal MDIO bus and in such cases the MDIO
      bus has to be scanned "manually" by the macb driver.
      
      Prior to the phylink conversion the driver registered the MDIO bus with
      of_mdiobus_register and then in case the PHY couldn't be retrieved
      using dt or using phy_find_first (because registering an MDIO bus with
      of_mdiobus_register masks all PHYs) the macb driver was "manually"
      scanning the MDIO bus (like mdiobus_register does). The phylink
      conversion did break this particular case but reimplementing the manual
      scan of the bus in the macb driver wouldn't be very clean. The solution
      seems to be registering the MDIO bus based on if the PHYs are described
      in the device tree or not.
      
      There are multiple ways to do this, none is perfect. I chose to check if
      any of the child nodes of the macb node was a network PHY and based on
      this to register the MDIO bus with the of_ helper or not. The drawback
      is boards referencing the PHY through phy-handle, would scan the entire
      MDIO bus of the macb at boot time (as the MDIO bus would be registered
      with mdiobus_register). For this solution to work properly
      of_mdiobus_child_is_phy has to be exported, which means the patch doing
      so has to be backported to -stable as well.
      
      Another possible solution could have been to simply check if the macb
      node has a child node by counting its sub-nodes. This isn't techically
      perfect, as there could be other sub-nodes (in practice this should be
      fine, fixed-link being taken care of in the driver). We could also
      simply s/of_mdiobus_register/mdiobus_register/ but that could break
      boards using the PHY description in child node as a selector (which
      really would be not a proper way to do this...).
      
      The real issue here being having PHYs not described in the dt but we
      have dt backward compatibility, so we have to live with that.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a019739c
    • Antoine Tenart's avatar
      net: macb: fix probing of PHY not described in the dt · ef8a2e27
      Antoine Tenart authored
      This patch fixes the case where the PHY isn't described in the device
      tree. This is due to the way the MDIO bus is registered in the driver:
      whether the PHY is described in the device tree or not, the bus is
      registered through of_mdiobus_register. The function masks all the PHYs
      and only allow probing the ones described in the device tree. Prior to
      the Phylink conversion this was also done but later on in the driver
      the MDIO bus was manually scanned to circumvent the fact that the PHY
      wasn't described.
      
      This patch fixes it in a proper way, by registering the MDIO bus based
      on if the PHY attached to a given interface is described in the device
      tree or not.
      
      Fixes: 7897b071 ("net: macb: convert to phylink")
      Signed-off-by: default avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef8a2e27
    • Antoine Tenart's avatar
      of: mdio: export of_mdiobus_child_is_phy · 0aa4d016
      Antoine Tenart authored
      This patch exports of_mdiobus_child_is_phy, allowing to check if a child
      node is a network PHY.
      Signed-off-by: default avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0aa4d016
  2. 19 Dec, 2019 9 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 0fd26005
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2019-12-19
      
      The following pull-request contains BPF updates for your *net* tree.
      
      We've added 10 non-merge commits during the last 8 day(s) which contain
      a total of 21 files changed, 269 insertions(+), 108 deletions(-).
      
      The main changes are:
      
      1) Fix lack of synchronization between xsk wakeup and destroying resources
         used by xsk wakeup, from Maxim Mikityanskiy.
      
      2) Fix pruning with tail call patching, untrack programs in case of verifier
         error and fix a cgroup local storage tracking bug, from Daniel Borkmann.
      
      3) Fix clearing skb->tstamp in bpf_redirect() when going from ingress to
         egress which otherwise cause issues e.g. on fq qdisc, from Lorenz Bauer.
      
      4) Fix compile warning of unused proc_dointvec_minmax_bpf_restricted() when
         only cBPF is present, from Alexander Lobakin.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0fd26005
    • Daniel Borkmann's avatar
      bpf: Add further test_verifier cases for record_func_key · 3123d801
      Daniel Borkmann authored
      Expand dummy prog generation such that we can easily check on return
      codes and add few more test cases to make sure we keep on tracking
      pruning behavior.
      
        # ./test_verifier
        [...]
        #1066/p XDP pkt read, pkt_data <= pkt_meta', bad access 1 OK
        #1067/p XDP pkt read, pkt_data <= pkt_meta', bad access 2 OK
        Summary: 1580 PASSED, 0 SKIPPED, 0 FAILED
      
      Also verified that JIT dump of added test cases looks good.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/df7200b6021444fd369376d227de917357285b65.1576789878.git.daniel@iogearbox.net
      3123d801
    • Daniel Borkmann's avatar
      bpf: Fix record_func_key to perform backtracking on r3 · cc52d914
      Daniel Borkmann authored
      While testing Cilium with /unreleased/ Linus' tree under BPF-based NodePort
      implementation, I noticed a strange BPF SNAT engine behavior from time to
      time. In some cases it would do the correct SNAT/DNAT service translation,
      but at a random point in time it would just stop and perform an unexpected
      translation after SYN, SYN/ACK and stack would send a RST back. While initially
      assuming that there is some sort of a race condition in BPF code, adding
      trace_printk()s for debugging purposes at some point seemed to have resolved
      the issue auto-magically.
      
      Digging deeper on this Heisenbug and reducing the trace_printk() calls to
      an absolute minimum, it turns out that a single call would suffice to
      trigger / not trigger the seen RST issue, even though the logic of the
      program itself remains unchanged. Turns out the single call changed verifier
      pruning behavior to get everything to work. Reconstructing a minimal test
      case, the incorrect JIT dump looked as follows:
      
        # bpftool p d j i 11346
        0xffffffffc0cba96c:
        [...]
          21:   movzbq 0x30(%rdi),%rax
          26:   cmp    $0xd,%rax
          2a:   je     0x000000000000003a
          2c:   xor    %edx,%edx
          2e:   movabs $0xffff89cc74e85800,%rsi
          38:   jmp    0x0000000000000049
          3a:   mov    $0x2,%edx
          3f:   movabs $0xffff89cc74e85800,%rsi
          49:   mov    -0x224(%rbp),%eax
          4f:   cmp    $0x20,%eax
          52:   ja     0x0000000000000062
          54:   add    $0x1,%eax
          57:   mov    %eax,-0x224(%rbp)
          5d:   jmpq   0xffffffffffff6911
          62:   mov    $0x1,%eax
        [...]
      
      Hence, unexpectedly, JIT emitted a direct jump even though retpoline based
      one would have been needed since in line 2c and 3a we have different slot
      keys in BPF reg r3. Verifier log of the test case reveals what happened:
      
        0: (b7) r0 = 14
        1: (73) *(u8 *)(r1 +48) = r0
        2: (71) r0 = *(u8 *)(r1 +48)
        3: (15) if r0 == 0xd goto pc+4
         R0_w=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R1=ctx(id=0,off=0,imm=0) R10=fp0
        4: (b7) r3 = 0
        5: (18) r2 = 0xffff89cc74d54a00
        7: (05) goto pc+3
        11: (85) call bpf_tail_call#12
        12: (b7) r0 = 1
        13: (95) exit
        from 3 to 8: R0_w=inv13 R1=ctx(id=0,off=0,imm=0) R10=fp0
        8: (b7) r3 = 2
        9: (18) r2 = 0xffff89cc74d54a00
        11: safe
        processed 13 insns (limit 1000000) [...]
      
      Second branch is pruned by verifier since considered safe, but issue is that
      record_func_key() couldn't have seen the index in line 3a and therefore
      decided that emitting a direct jump at this location was okay.
      
      Fix this by reusing our backtracking logic for precise scalar verification
      in order to prevent pruning on the slot key. This means verifier will track
      content of r3 all the way backwards and only prune if both scalars were
      unknown in state equivalence check and therefore poisoned in the first place
      in record_func_key(). The range is [x,x] in record_func_key() case since
      the slot always would have to be constant immediate. Correct verification
      after fix:
      
        0: (b7) r0 = 14
        1: (73) *(u8 *)(r1 +48) = r0
        2: (71) r0 = *(u8 *)(r1 +48)
        3: (15) if r0 == 0xd goto pc+4
         R0_w=invP(id=0,umax_value=255,var_off=(0x0; 0xff)) R1=ctx(id=0,off=0,imm=0) R10=fp0
        4: (b7) r3 = 0
        5: (18) r2 = 0x0
        7: (05) goto pc+3
        11: (85) call bpf_tail_call#12
        12: (b7) r0 = 1
        13: (95) exit
        from 3 to 8: R0_w=invP13 R1=ctx(id=0,off=0,imm=0) R10=fp0
        8: (b7) r3 = 2
        9: (18) r2 = 0x0
        11: (85) call bpf_tail_call#12
        12: (b7) r0 = 1
        13: (95) exit
        processed 15 insns (limit 1000000) [...]
      
      And correct corresponding JIT dump:
      
        # bpftool p d j i 11
        0xffffffffc0dc34c4:
        [...]
          21:	  movzbq 0x30(%rdi),%rax
          26:	  cmp    $0xd,%rax
          2a:	  je     0x000000000000003a
          2c:	  xor    %edx,%edx
          2e:	  movabs $0xffff9928b4c02200,%rsi
          38:	  jmp    0x0000000000000049
          3a:	  mov    $0x2,%edx
          3f:	  movabs $0xffff9928b4c02200,%rsi
          49:	  cmp    $0x4,%rdx
          4d:	  jae    0x0000000000000093
          4f:	  and    $0x3,%edx
          52:	  mov    %edx,%edx
          54:	  cmp    %edx,0x24(%rsi)
          57:	  jbe    0x0000000000000093
          59:	  mov    -0x224(%rbp),%eax
          5f:	  cmp    $0x20,%eax
          62:	  ja     0x0000000000000093
          64:	  add    $0x1,%eax
          67:	  mov    %eax,-0x224(%rbp)
          6d:	  mov    0x110(%rsi,%rdx,8),%rax
          75:	  test   %rax,%rax
          78:	  je     0x0000000000000093
          7a:	  mov    0x30(%rax),%rax
          7e:	  add    $0x19,%rax
          82:   callq  0x000000000000008e
          87:   pause
          89:   lfence
          8c:   jmp    0x0000000000000087
          8e:   mov    %rax,(%rsp)
          92:   retq
          93:   mov    $0x1,%eax
        [...]
      
      Also explicitly adding explicit env->allow_ptr_leaks to fixup_bpf_calls() since
      backtracking is enabled under former (direct jumps as well, but use different
      test). In case of only tracking different map pointers as in c93552c4 ("bpf:
      properly enforce index mask to prevent out-of-bounds speculation"), pruning
      cannot make such short-cuts, neither if there are paths with scalar and non-scalar
      types as r3. mark_chain_precision() is only needed after we know that
      register_is_const(). If it was not the case, we already poison the key on first
      path and non-const key in later paths are not matching the scalar range in regsafe()
      either. Cilium NodePort testing passes fine as well now. Note, released kernels
      not affected.
      
      Fixes: d2e4c1e6 ("bpf: Constant map key tracking for prog array pokes")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/ac43ffdeb7386c5bd688761ed266f3722bb39823.1576789878.git.daniel@iogearbox.net
      cc52d914
    • Alexander Lobakin's avatar
      net, sysctl: Fix compiler warning when only cBPF is present · 1148f9ad
      Alexander Lobakin authored
      proc_dointvec_minmax_bpf_restricted() has been firstly introduced
      in commit 2e4a3098 ("bpf: restrict access to core bpf sysctls")
      under CONFIG_HAVE_EBPF_JIT. Then, this ifdef has been removed in
      ede95a63 ("bpf: add bpf_jit_limit knob to restrict unpriv
      allocations"), because a new sysctl, bpf_jit_limit, made use of it.
      Finally, this parameter has become long instead of integer with
      fdadd049 ("bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K")
      and thus, a new proc_dolongvec_minmax_bpf_restricted() has been
      added.
      
      With this last change, we got back to that
      proc_dointvec_minmax_bpf_restricted() is used only under
      CONFIG_HAVE_EBPF_JIT, but the corresponding ifdef has not been
      brought back.
      
      So, in configurations like CONFIG_BPF_JIT=y && CONFIG_HAVE_EBPF_JIT=n
      since v4.20 we have:
      
        CC      net/core/sysctl_net_core.o
      net/core/sysctl_net_core.c:292:1: warning: ‘proc_dointvec_minmax_bpf_restricted’ defined but not used [-Wunused-function]
        292 | proc_dointvec_minmax_bpf_restricted(struct ctl_table *table, int write,
            | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Suppress this by guarding it with CONFIG_HAVE_EBPF_JIT again.
      
      Fixes: fdadd049 ("bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K")
      Signed-off-by: default avatarAlexander Lobakin <alobakin@dlink.ru>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20191218091821.7080-1-alobakin@dlink.ru
      1148f9ad
    • Daniel Borkmann's avatar
      Merge branch 'bpf-fix-xsk-wakeup' · ca8d0fa7
      Daniel Borkmann authored
      Maxim Mikityanskiy says:
      
      ====================
      This series addresses the issue described in the commit message of the
      first patch: lack of synchronization between XSK wakeup and destroying
      the resources used by XSK wakeup. The idea is similar to napi_synchronize.
      The series contains fixes for the drivers that implement XSK.
      
      v2 incorporates changes suggested by Björn:
      
      1. Call synchronize_rcu in Intel drivers only if the XDP program is
         being unloaded.
      2. Don't forget rcu_read_lock when wakeup is called from xsk_poll.
      3. Use xs->zc as the condition to call ndo_xsk_wakeup.
      ====================
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      ca8d0fa7
    • Maxim Mikityanskiy's avatar
      net/ixgbe: Fix concurrency issues between config flow and XSK · c0fdccfd
      Maxim Mikityanskiy authored
      Use synchronize_rcu to wait until the XSK wakeup function finishes
      before destroying the resources it uses:
      
      1. ixgbe_down already calls synchronize_rcu after setting __IXGBE_DOWN.
      
      2. After switching the XDP program, call synchronize_rcu to let
      ixgbe_xsk_wakeup exit before the XDP program is freed.
      
      3. Changing the number of channels brings the interface down.
      
      4. Disabling UMEM sets __IXGBE_TX_DISABLED before closing hardware
      resources and resetting xsk_umem. Check that bit in ixgbe_xsk_wakeup to
      avoid using the XDP ring when it's already destroyed. synchronize_rcu is
      called from ixgbe_txrx_ring_disable.
      Signed-off-by: default avatarMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: default avatarBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20191217162023.16011-5-maximmi@mellanox.com
      c0fdccfd
    • Maxim Mikityanskiy's avatar
      net/i40e: Fix concurrency issues between config flow and XSK · b3873a5b
      Maxim Mikityanskiy authored
      Use synchronize_rcu to wait until the XSK wakeup function finishes
      before destroying the resources it uses:
      
      1. i40e_down already calls synchronize_rcu. On i40e_down either
      __I40E_VSI_DOWN or __I40E_CONFIG_BUSY is set. Check the latter in
      i40e_xsk_wakeup (the former is already checked there).
      
      2. After switching the XDP program, call synchronize_rcu to let
      i40e_xsk_wakeup exit before the XDP program is freed.
      
      3. Changing the number of channels brings the interface down (see
      i40e_prep_for_reset and i40e_pf_quiesce_all_vsi).
      
      4. Disabling UMEM sets __I40E_CONFIG_BUSY, too.
      Signed-off-by: default avatarMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: default avatarBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20191217162023.16011-4-maximmi@mellanox.com
      b3873a5b
    • Maxim Mikityanskiy's avatar
      net/mlx5e: Fix concurrency issues between config flow and XSK · 9cf88808
      Maxim Mikityanskiy authored
      After disabling resources necessary for XSK (the XDP program, channels,
      XSK queues), use synchronize_rcu to wait until the XSK wakeup function
      finishes, before freeing the resources.
      
      Suspend XSK wakeups during switching channels. If the XDP program is
      being removed, synchronize_rcu before closing the old channels to allow
      XSK wakeup to complete.
      Signed-off-by: default avatarMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20191217162023.16011-3-maximmi@mellanox.com
      9cf88808
    • Maxim Mikityanskiy's avatar
      xsk: Add rcu_read_lock around the XSK wakeup · 06870682
      Maxim Mikityanskiy authored
      The XSK wakeup callback in drivers makes some sanity checks before
      triggering NAPI. However, some configuration changes may occur during
      this function that affect the result of those checks. For example, the
      interface can go down, and all the resources will be destroyed after the
      checks in the wakeup function, but before it attempts to use these
      resources. Wrap this callback in rcu_read_lock to allow driver to
      synchronize_rcu before actually destroying the resources.
      
      xsk_wakeup is a new function that encapsulates calling ndo_xsk_wakeup
      wrapped into the RCU lock. After this commit, xsk_poll starts using
      xsk_wakeup and checks xs->zc instead of ndo_xsk_wakeup != NULL to decide
      ndo_xsk_wakeup should be called. It also fixes a bug introduced with the
      need_wakeup feature: a non-zero-copy socket may be used with a driver
      supporting zero-copy, and in this case ndo_xsk_wakeup should not be
      called, so the xs->zc check is the correct one.
      
      Fixes: 77cd0d7b ("xsk: add support for need_wakeup flag in AF_XDP rings")
      Signed-off-by: default avatarMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: default avatarBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20191217162023.16011-2-maximmi@mellanox.com
      06870682
  3. 18 Dec, 2019 19 commits
  4. 17 Dec, 2019 5 commits
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-2019-12-17' of... · 040cda8a
      David S. Miller authored
      Merge tag 'wireless-drivers-2019-12-17' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for v5.5
      
      First set of fixes for v5.5. Fixing security issues, some regressions
      and few major bugs.
      
      mwifiex
      
      * security fix for handling country Information Elements (CVE-2019-14895)
      
      * security fix for handling TDLS Information Elements
      
      ath9k
      
      * fix endian issue with ath9k_pci_owl_loader
      
      mt76
      
      * fix default mac address handling
      
      iwlwifi
      
      * fix merge damage which lead to firmware crashing during boot on some devices
      
      * fix device initialisation regression on some devices
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      040cda8a
    • Ioana Ciornei's avatar
      dpaa2-ptp: fix double free of the ptp_qoriq IRQ · daa6eb5a
      Ioana Ciornei authored
      Upon reusing the ptp_qoriq driver, the ptp_qoriq_free() function was
      used on the remove path to free any allocated resources.
      The ptp_qoriq IRQ is among these resources that are freed in
      ptp_qoriq_free() even though it is also a managed one (allocated using
      devm_request_threaded_irq).
      
      Drop the resource managed version of requesting the IRQ in order to not
      trigger a double free of the interrupt as below:
      
      [  226.731005] Trying to free already-free IRQ 126
      [  226.735533] WARNING: CPU: 6 PID: 749 at kernel/irq/manage.c:1707
      __free_irq+0x9c/0x2b8
      [  226.743435] Modules linked in:
      [  226.746480] CPU: 6 PID: 749 Comm: bash Tainted: G        W
      5.4.0-03629-gfd7102c32b2c-dirty #912
      [  226.755857] Hardware name: NXP Layerscape LX2160ARDB (DT)
      [  226.761244] pstate: 40000085 (nZcv daIf -PAN -UAO)
      [  226.766022] pc : __free_irq+0x9c/0x2b8
      [  226.769758] lr : __free_irq+0x9c/0x2b8
      [  226.773493] sp : ffff8000125039f0
      (...)
      [  226.856275] Call trace:
      [  226.858710]  __free_irq+0x9c/0x2b8
      [  226.862098]  free_irq+0x30/0x70
      [  226.865229]  devm_irq_release+0x14/0x20
      [  226.869054]  release_nodes+0x1b0/0x220
      [  226.872790]  devres_release_all+0x34/0x50
      [  226.876790]  device_release_driver_internal+0x100/0x1c0
      
      Fixes: d346c9e8 ("dpaa2-ptp: reuse ptp_qoriq driver")
      Cc: Yangbo Lu <yangbo.lu@nxp.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Reviewed-by: default avatarYangbo Lu <yangbo.lu@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      daa6eb5a
    • Daniel Borkmann's avatar
      bpf: Fix cgroup local storage prog tracking · e4730423
      Daniel Borkmann authored
      Recently noticed that we're tracking programs related to local storage maps
      through their prog pointer. This is a wrong assumption since the prog pointer
      can still change throughout the verification process, for example, whenever
      bpf_patch_insn_single() is called.
      
      Therefore, the prog pointer that was assigned via bpf_cgroup_storage_assign()
      is not guaranteed to be the same as we pass in bpf_cgroup_storage_release()
      and the map would therefore remain in busy state forever. Fix this by using
      the prog's aux pointer which is stable throughout verification and beyond.
      
      Fixes: de9cbbaa ("bpf: introduce cgroup storage maps")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Martin KaFai Lau <kafai@fb.com>
      Link: https://lore.kernel.org/bpf/1471c69eca3022218666f909bc927a92388fd09e.1576580332.git.daniel@iogearbox.net
      e4730423
    • David S. Miller's avatar
      Merge tag 'mac80211-for-net-2019-10-16' of... · ad125c6c
      David S. Miller authored
      Merge tag 'mac80211-for-net-2019-10-16' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      A handful of fixes:
       * disable AQL on most drivers, addressing the iwlwifi issues
       * fix double-free on network namespace changes
       * fix TID field in frames injected through monitor interfaces
       * fix ieee80211_calc_rx_airtime()
       * fix NULL pointer dereference in rfkill (and remove BUG_ON)
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad125c6c
    • Arnd Bergmann's avatar
      net: dsa: ocelot: add NET_VENDOR_MICROSEMI dependency · 95bed1a9
      Arnd Bergmann authored
      Selecting MSCC_OCELOT_SWITCH is not possible when NET_VENDOR_MICROSEMI
      is disabled:
      
      WARNING: unmet direct dependencies detected for MSCC_OCELOT_SWITCH
        Depends on [n]: NETDEVICES [=y] && ETHERNET [=n] && NET_VENDOR_MICROSEMI [=n] && NET_SWITCHDEV [=y] && HAS_IOMEM [=y]
        Selected by [m]:
        - NET_DSA_MSCC_FELIX [=m] && NETDEVICES [=y] && HAVE_NET_DSA [=y] && NET_DSA [=y] && PCI [=y]
      
      Add a Kconfig dependency on NET_VENDOR_MICROSEMI, which also implies
      CONFIG_NETDEVICES.
      
      Depending on a vendor config violates menuconfig locality for the DSA
      driver, but is the smallest compromise since all other solutions are
      much more complicated (see [0]).
      
      https://www.spinics.net/lists/netdev/msg618808.html
      
      Fixes: 56051948 ("net: dsa: ocelot: add driver for Felix switch family")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMao Wenan <maowenan@huawei.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      95bed1a9