You need to sign in or sign up before continuing.
  1. 06 4月, 2016 5 次提交
    • B
      mac80211: mesh: handle failed alloc for rmc cache · 0aa7fabb
      Bob Copeland 提交于
      In the unlikely case that mesh_rmc_init() fails with -ENOMEM,
      the rmc pointer will be left as NULL but the interface is still
      operational because ieee80211_mesh_init_sdata() is not allowed
      to fail.
      
      If this happens, we would blindly dereference rmc when checking
      whether a multicast frame is in the cache.  Instead just drop the
      frames in the forwarding path.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0aa7fabb
    • B
      mac80211: mesh: fix crash in mesh_path_timer · 74932959
      Bob Copeland 提交于
      The mesh_path_reclaim() function, called from an rcu callback, cancels
      the mesh_path_timer associated with a mesh path.  Unfortunately, this
      call can happen much later, perhaps after the hash table itself is
      destroyed.
      
      Such a situation led to the following crash in mesh_path_send_to_gates()
      when dereferencing the tbl pointer:
      
      [   23.901661] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      [   23.905516] IP: [<ffffffff814c910b>] mesh_path_send_to_gates+0x2b/0x740
      [   23.908757] PGD 99ca067 PUD 99c4067 PMD 0
      [   23.910789] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      [   23.913485] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-wt+ #43
      [   23.916675] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
      [   23.920471] task: ffffffff81685500 ti: ffffffff81678000 task.ti: ffffffff81678000
      [   23.922619] RIP: 0010:[<ffffffff814c910b>]  [<ffffffff814c910b>] mesh_path_send_to_gates+0x2b/0x740
      [   23.925237] RSP: 0018:ffff88000b403d30  EFLAGS: 00010286
      [   23.926739] RAX: 0000000000000000 RBX: ffff880009bc0d20 RCX: 0000000000000102
      [   23.928796] RDX: 000000000000002e RSI: 0000000000000001 RDI: ffff880009bc0d20
      [   23.930895] RBP: ffff88000b403e18 R08: 0000000000000001 R09: 0000000000000001
      [   23.932917] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880009c20940
      [   23.936370] R13: ffff880009bc0e70 R14: ffff880009c21c40 R15: ffff880009bc0d20
      [   23.939823] FS:  0000000000000000(0000) GS:ffff88000b400000(0000) knlGS:0000000000000000
      [   23.943688] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [   23.946429] CR2: 0000000000000008 CR3: 00000000099c5000 CR4: 00000000000006b0
      [   23.949861] Stack:
      [   23.950840]  000000000000002e ffff880009c20940 ffff88000b403da8 ffffffff8109e551
      [   23.954467]  ffffffff82711be2 000000000000002e 0000000000000000 ffffffff8166a5f5
      [   23.958141]  0000000000685ce8 0000000000000246 ffff880009bc0d20 ffff880009c20940
      [   23.961801] Call Trace:
      [   23.962987]  <IRQ>
      [   23.963963]  [<ffffffff8109e551>] ? vprintk_emit+0x351/0x5e0
      [   23.966782]  [<ffffffff8109e8ff>] ? vprintk_default+0x1f/0x30
      [   23.969529]  [<ffffffff810ffa41>] ? printk+0x48/0x50
      [   23.971956]  [<ffffffff814ceef3>] mesh_path_timer+0x133/0x160
      [   23.974707]  [<ffffffff814cedc0>] ? mesh_nexthop_resolve+0x230/0x230
      [   23.977775]  [<ffffffff810b04ee>] call_timer_fn+0xce/0x330
      [   23.980448]  [<ffffffff810b0425>] ? call_timer_fn+0x5/0x330
      [   23.983126]  [<ffffffff814cedc0>] ? mesh_nexthop_resolve+0x230/0x230
      [   23.986091]  [<ffffffff810b097c>] run_timer_softirq+0x22c/0x390
      
      Instead of cancelling in the RCU callback, set a new flag to prevent the
      timer from being rearmed, and then cancel the timer synchronously when
      freeing the mesh path.  This leaves mesh_path_reclaim() doing nothing
      but kfree, so switch to kfree_rcu().
      
      Fixes: 3b302ada7f0a ("mac80211: mesh: move path tables into if_mesh")
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      74932959
    • A
      mac80211: track and tell driver about GO client P2P PS abilities · 52cfa1d6
      Ayala Beker 提交于
      Legacy clients don't support P2P power save mechanism, and thus if a P2P GO
      has a legacy client connected to it, it should disable P2P PS mechanisms.
      Let the driver know about this with a new bss_conf parameter.
      Signed-off-by: NAyala Beker <ayala.beker@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      52cfa1d6
    • A
      cfg80211: allow userspace to specify client P2P PS support · 17b94247
      Ayala Beker 提交于
      Legacy clients don't support P2P power save mechanisms, and thus
      if a P2P GO has a legacy client connected to it, it has to make
      some changes in the PS behavior.
      
      To handle this, add an attribute to specify whether a station supports
      P2P PS or not. If the attribute was not specified cfg80211 will assume
      that station supports it for P2P GO interface, and does NOT support it
      for AP interface, matching the current assumptions in the code.
      Signed-off-by: NAyala Beker <ayala.beker@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      17b94247
    • J
      mac80211: avoid useless memory write on each frame RX · b100e5d6
      Johannes Berg 提交于
      In the likely case that probe_count is 0, don't write to the
      memory there.
      
      Also use ifmgd consistently in the function, instead of using
      sdata->u.mgd as well.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b100e5d6
  2. 05 4月, 2016 26 次提交
  3. 02 4月, 2016 1 次提交
    • D
      tun, bpf: fix suspicious RCU usage in tun_{attach, detach}_filter · 5a5abb1f
      Daniel Borkmann 提交于
      Sasha Levin reported a suspicious rcu_dereference_protected() warning
      found while fuzzing with trinity that is similar to this one:
      
        [   52.765684] net/core/filter.c:2262 suspicious rcu_dereference_protected() usage!
        [   52.765688] other info that might help us debug this:
        [   52.765695] rcu_scheduler_active = 1, debug_locks = 1
        [   52.765701] 1 lock held by a.out/1525:
        [   52.765704]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff816a64b7>] rtnl_lock+0x17/0x20
        [   52.765721] stack backtrace:
        [   52.765728] CPU: 1 PID: 1525 Comm: a.out Not tainted 4.5.0+ #264
        [...]
        [   52.765768] Call Trace:
        [   52.765775]  [<ffffffff813e488d>] dump_stack+0x85/0xc8
        [   52.765784]  [<ffffffff810f2fa5>] lockdep_rcu_suspicious+0xd5/0x110
        [   52.765792]  [<ffffffff816afdc2>] sk_detach_filter+0x82/0x90
        [   52.765801]  [<ffffffffa0883425>] tun_detach_filter+0x35/0x90 [tun]
        [   52.765810]  [<ffffffffa0884ed4>] __tun_chr_ioctl+0x354/0x1130 [tun]
        [   52.765818]  [<ffffffff8136fed0>] ? selinux_file_ioctl+0x130/0x210
        [   52.765827]  [<ffffffffa0885ce3>] tun_chr_ioctl+0x13/0x20 [tun]
        [   52.765834]  [<ffffffff81260ea6>] do_vfs_ioctl+0x96/0x690
        [   52.765843]  [<ffffffff81364af3>] ? security_file_ioctl+0x43/0x60
        [   52.765850]  [<ffffffff81261519>] SyS_ioctl+0x79/0x90
        [   52.765858]  [<ffffffff81003ba2>] do_syscall_64+0x62/0x140
        [   52.765866]  [<ffffffff817d563f>] entry_SYSCALL64_slow_path+0x25/0x25
      
      Same can be triggered with PROVE_RCU (+ PROVE_RCU_REPEATEDLY) enabled
      from tun_attach_filter() when user space calls ioctl(tun_fd, TUN{ATTACH,
      DETACH}FILTER, ...) for adding/removing a BPF filter on tap devices.
      
      Since the fix in f91ff5b9 ("net: sk_{detach|attach}_filter() rcu
      fixes") sk_attach_filter()/sk_detach_filter() now dereferences the
      filter with rcu_dereference_protected(), checking whether socket lock
      is held in control path.
      
      Since its introduction in 99405162 ("tun: socket filter support"),
      tap filters are managed under RTNL lock from __tun_chr_ioctl(). Thus the
      sock_owned_by_user(sk) doesn't apply in this specific case and therefore
      triggers the false positive.
      
      Extend the BPF API with __sk_attach_filter()/__sk_detach_filter() pair
      that is used by tap filters and pass in lockdep_rtnl_is_held() for the
      rcu_dereference_protected() checks instead.
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a5abb1f
  4. 01 4月, 2016 1 次提交
  5. 31 3月, 2016 5 次提交
  6. 28 3月, 2016 2 次提交