Skip to content
Snippets Groups Projects
  1. Feb 06, 2014
    • Johannes Berg's avatar
      cfg80211: fix scan done race · a617302c
      Johannes Berg authored
      
      When an interface/wdev is removed, any ongoing scan should be
      cancelled by the driver. This will make it call cfg80211, which
      only queues a work struct. If interface/wdev removal is quick
      enough, this can leave the scan request pending and processed
      only after the interface is gone, causing a use-after-free.
      
      Fix this by making sure the scan request is not pending after
      the interface is destroyed. We can't flush or cancel the work
      item due to locking concerns, but when it'll run it shouldn't
      find anything to do. This leaves a potential issue, if a new
      scan gets requested before the work runs, it prematurely stops
      the running scan, potentially causing another crash. I'll fix
      that in the next patch.
      
      This was particularly observed with P2P_DEVICE wdevs, likely
      because freeing them is quicker than freeing netdevs.
      
      Reported-by: default avatarAndrei Otcheretianski <andrei.otcheretianski@intel.com>
      Fixes: 4a58e7c3 ("cfg80211: don't "leak" uncompleted scans")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      a617302c
    • Emmanuel Grumbach's avatar
      mac80211: avoid deadlock revealed by lockdep · 8ffcc704
      Emmanuel Grumbach authored
      
      sdata->u.ap.request_smps_work can’t be flushed synchronously
      under wdev_lock(wdev) since ieee80211_request_smps_ap_work
      itself locks the same lock.
      While at it, reset the driver_smps_mode when the ap is
      stopped to its default: OFF.
      
      This solves:
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.12.0-ipeer+ #2 Tainted: G           O
      -------------------------------------------------------
      rmmod/2867 is trying to acquire lock:
        ((&sdata->u.ap.request_smps_work)){+.+...}, at: [<c105b8d0>] flush_work+0x0/0x90
      
      but task is already holding lock:
        (&wdev->mtx){+.+.+.}, at: [<f9b32626>] cfg80211_stop_ap+0x26/0x230 [cfg80211]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&wdev->mtx){+.+.+.}:
              [<c10aefa9>] lock_acquire+0x79/0xe0
              [<c1607a1a>] mutex_lock_nested+0x4a/0x360
              [<fb06288b>] ieee80211_request_smps_ap_work+0x2b/0x50 [mac80211]
              [<c105cdd8>] process_one_work+0x198/0x450
              [<c105d469>] worker_thread+0xf9/0x320
              [<c10669ff>] kthread+0x9f/0xb0
              [<c1613397>] ret_from_kernel_thread+0x1b/0x28
      
      -> #0 ((&sdata->u.ap.request_smps_work)){+.+...}:
              [<c10ae9df>] __lock_acquire+0x183f/0x1910
              [<c10aefa9>] lock_acquire+0x79/0xe0
              [<c105b917>] flush_work+0x47/0x90
              [<c105d867>] __cancel_work_timer+0x67/0xe0
              [<c105d90f>] cancel_work_sync+0xf/0x20
              [<fb0765cc>] ieee80211_stop_ap+0x8c/0x340 [mac80211]
              [<f9b3268c>] cfg80211_stop_ap+0x8c/0x230 [cfg80211]
              [<f9b0d8f9>] cfg80211_leave+0x79/0x100 [cfg80211]
              [<f9b0da72>] cfg80211_netdev_notifier_call+0xf2/0x4f0 [cfg80211]
              [<c160f2c9>] notifier_call_chain+0x59/0x130
              [<c106c6de>] __raw_notifier_call_chain+0x1e/0x30
              [<c106c70f>] raw_notifier_call_chain+0x1f/0x30
              [<c14f8213>] call_netdevice_notifiers_info+0x33/0x70
              [<c14f8263>] call_netdevice_notifiers+0x13/0x20
              [<c14f82a4>] __dev_close_many+0x34/0xb0
              [<c14f83fe>] dev_close_many+0x6e/0xc0
              [<c14f9c77>] rollback_registered_many+0xa7/0x1f0
              [<c14f9dd4>] unregister_netdevice_many+0x14/0x60
              [<fb06f4d9>] ieee80211_remove_interfaces+0xe9/0x170 [mac80211]
              [<fb055116>] ieee80211_unregister_hw+0x56/0x110 [mac80211]
              [<fa3e9396>] iwl_op_mode_mvm_stop+0x26/0xe0 [iwlmvm]
              [<f9b9d8ca>] _iwl_op_mode_stop+0x3a/0x70 [iwlwifi]
              [<f9b9d96f>] iwl_opmode_deregister+0x6f/0x90 [iwlwifi]
              [<fa405179>] __exit_compat+0xd/0x19 [iwlmvm]
              [<c10b8bf9>] SyS_delete_module+0x179/0x2b0
              [<c1613421>] sysenter_do_call+0x12/0x32
      
      Fixes: 687da132 ("mac80211: implement SMPS for AP")
      Cc: <stable@vger.kernel.org> [3.13]
      Reported-by: default avatarIlan Peer <ilan.peer@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8ffcc704
    • Johannes Berg's avatar
      cfg80211: re-enable 5/10 MHz support · 5a6aa705
      Johannes Berg authored
      
      Unfortunately I forgot this during the merge window, but the
      patch seems small enough to go in as a fix. The userspace API
      bug that was the reason for disabling it has long been fixed.
      
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      5a6aa705
    • Pontus Fuchs's avatar
      nl80211: Reset split_start when netlink skb is exhausted · f12cb289
      Pontus Fuchs authored
      
      When the netlink skb is exhausted split_start is left set. In the
      subsequent retry, with a larger buffer, the dump is continued from the
      failing point instead of from the beginning.
      
      This was causing my rt28xx based USB dongle to now show up when
      running "iw list" with an old iw version without split dump support.
      
      Cc: stable@vger.kernel.org
      Fixes: 3713b4e3 ("nl80211: allow splitting wiphy information in dumps")
      Signed-off-by: default avatarPontus Fuchs <pontus.fuchs@gmail.com>
      [avoid the entire workaround when state->split is set]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f12cb289
    • Eliad Peller's avatar
      mac80211: move roc cookie assignment earlier · 2f617435
      Eliad Peller authored
      
      ieee80211_start_roc_work() might add a new roc
      to existing roc, and tell cfg80211 it has already
      started.
      
      However, this might happen before the roc cookie
      was set, resulting in REMAIN_ON_CHANNEL (started)
      event with null cookie. Consequently, it can make
      wpa_supplicant go out of sync.
      
      Fix it by setting the roc cookie earlier.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      2f617435
  2. Jan 29, 2014
    • Masanari Iida's avatar
      net: Fix warning on make htmldocs caused by skbuff.c · 7fceb4de
      Masanari Iida authored
      
      This patch fixed following Warning while executing "make htmldocs".
      
      Warning(/net/core/skbuff.c:2164): No description found for parameter 'from'
      Warning(/net/core/skbuff.c:2164): Excess function parameter 'source'
      description in 'skb_zerocopy'
      Replace "@source" with "@from" fixed the warning.
      
      Signed-off-by: default avatarMasanari Iida <standby24x7@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7fceb4de
    • Dave Jones's avatar
      llc: remove noisy WARN from llc_mac_hdr_init · 0f1a24c9
      Dave Jones authored
      
      Sending malformed llc packets triggers this spew, which seems excessive.
      
      WARNING: CPU: 1 PID: 6917 at net/llc/llc_output.c:46 llc_mac_hdr_init+0x85/0x90 [llc]()
      device type not supported: 0
      CPU: 1 PID: 6917 Comm: trinity-c1 Not tainted 3.13.0+ #95
       0000000000000009 00000000007e257d ffff88009232fbe8 ffffffffac737325
       ffff88009232fc30 ffff88009232fc20 ffffffffac06d28d ffff88020e07f180
       ffff88009232fec0 00000000000000c8 0000000000000000 ffff88009232fe70
      Call Trace:
       [<ffffffffac737325>] dump_stack+0x4e/0x7a
       [<ffffffffac06d28d>] warn_slowpath_common+0x7d/0xa0
       [<ffffffffac06d30c>] warn_slowpath_fmt+0x5c/0x80
       [<ffffffffc01736d5>] llc_mac_hdr_init+0x85/0x90 [llc]
       [<ffffffffc0173759>] llc_build_and_send_ui_pkt+0x79/0x90 [llc]
       [<ffffffffc057cdba>] llc_ui_sendmsg+0x23a/0x400 [llc2]
       [<ffffffffac605d8c>] sock_sendmsg+0x9c/0xe0
       [<ffffffffac185a37>] ? might_fault+0x47/0x50
       [<ffffffffac606321>] SYSC_sendto+0x121/0x1c0
       [<ffffffffac011847>] ? syscall_trace_enter+0x207/0x270
       [<ffffffffac6071ce>] SyS_sendto+0xe/0x10
       [<ffffffffac74aaa4>] tracesys+0xdd/0xe2
      
      Until 2009, this was a printk, when it was changed in
      bf9ae538: "llc: use dev_hard_header".
      
      Let userland figure out what -EINVAL means by itself.
      
      Signed-off-by: default avatarDave Jones <davej@fedoraproject.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0f1a24c9
  3. Jan 28, 2014
    • Duan Jiong's avatar
      net: gre: use icmp_hdr() to get inner ip header · c0c0c50f
      Duan Jiong authored
      
      When dealing with icmp messages, the skb->data points the
      ip header that triggered the sending of the icmp message.
      
      In gre_cisco_err(), the parse_gre_header() is called, and the
      iptunnel_pull_header() is called to pull the skb at the end of
      the parse_gre_header(), so the skb->data doesn't point the
      inner ip header.
      
      Unfortunately, the ipgre_err still needs those ip addresses in
      inner ip header to look up tunnel by ip_tunnel_lookup().
      
      So just use icmp_hdr() to get inner ip header instead of skb->data.
      
      Signed-off-by: default avatarDuan Jiong <duanj.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0c0c50f
    • Stephen Rothwell's avatar
      ce60e0c4
    • Holger Eitzenberger's avatar
      net: Fix memory leak if TPROXY used with TCP early demux · a452ce34
      Holger Eitzenberger authored
      
      I see a memory leak when using a transparent HTTP proxy using TPROXY
      together with TCP early demux and Kernel v3.8.13.15 (Ubuntu stable):
      
      unreferenced object 0xffff88008cba4a40 (size 1696):
        comm "softirq", pid 0, jiffies 4294944115 (age 8907.520s)
        hex dump (first 32 bytes):
          0a e0 20 6a 40 04 1b 37 92 be 32 e2 e8 b4 00 00  .. j@..7..2.....
          02 00 07 01 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff810b710a>] kmem_cache_alloc+0xad/0xb9
          [<ffffffff81270185>] sk_prot_alloc+0x29/0xc5
          [<ffffffff812702cf>] sk_clone_lock+0x14/0x283
          [<ffffffff812aaf3a>] inet_csk_clone_lock+0xf/0x7b
          [<ffffffff8129a893>] netlink_broadcast+0x14/0x16
          [<ffffffff812c1573>] tcp_create_openreq_child+0x1b/0x4c3
          [<ffffffff812c033e>] tcp_v4_syn_recv_sock+0x38/0x25d
          [<ffffffff812c13e4>] tcp_check_req+0x25c/0x3d0
          [<ffffffff812bf87a>] tcp_v4_do_rcv+0x287/0x40e
          [<ffffffff812a08a7>] ip_route_input_noref+0x843/0xa55
          [<ffffffff812bfeca>] tcp_v4_rcv+0x4c9/0x725
          [<ffffffff812a26f4>] ip_local_deliver_finish+0xe9/0x154
          [<ffffffff8127a927>] __netif_receive_skb+0x4b2/0x514
          [<ffffffff8127aa77>] process_backlog+0xee/0x1c5
          [<ffffffff8127c949>] net_rx_action+0xa7/0x200
          [<ffffffff81209d86>] add_interrupt_randomness+0x39/0x157
      
      But there are many more, resulting in the machine going OOM after some
      days.
      
      From looking at the TPROXY code, and with help from Florian, I see
      that the memory leak is introduced in tcp_v4_early_demux():
      
        void tcp_v4_early_demux(struct sk_buff *skb)
        {
          /* ... */
      
          iph = ip_hdr(skb);
          th = tcp_hdr(skb);
      
          if (th->doff < sizeof(struct tcphdr) / 4)
              return;
      
          sk = __inet_lookup_established(dev_net(skb->dev), &tcp_hashinfo,
                             iph->saddr, th->source,
                             iph->daddr, ntohs(th->dest),
                             skb->skb_iif);
          if (sk) {
              skb->sk = sk;
      
      where the socket is assigned unconditionally to skb->sk, also bumping
      the refcnt on it.  This is problematic, because in our case the skb
      has already a socket assigned in the TPROXY target.  This then results
      in the leak I see.
      
      The very same issue seems to be with IPv6, but haven't tested.
      
      Reviewed-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarHolger Eitzenberger <holger@eitzenberger.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a452ce34
  4. Jan 27, 2014
  5. Jan 26, 2014
    • Tim Smith's avatar
      af_rxrpc: Handle frames delivered from another VM · 1ea42735
      Tim Smith authored
      
      On input, CHECKSUM_PARTIAL should be treated the same way as
      CHECKSUM_UNNECESSARY. See include/linux/skbuff.h
      
      Signed-off-by: default avatarTim Smith <tim@electronghost.co.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      1ea42735
    • Tim Smith's avatar
      af_rxrpc: Avoid setting up double-free on checksum error · 24a9981e
      Tim Smith authored
      
      skb_kill_datagram() does not dequeue the skb when MSG_PEEK is unset.
      This leaves a free'd skb on the queue, resulting a double-free later.
      
      Without this, the following oops can occur:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      IP: [<ffffffff8154fcf7>] skb_dequeue+0x47/0x70
      PGD 0
      Oops: 0002 [#1] SMP
      Modules linked in: af_rxrpc ...
      CPU: 0 PID: 1191 Comm: listen Not tainted 3.12.0+ #4
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      task: ffff8801183536b0 ti: ffff880035c92000 task.ti: ffff880035c92000
      RIP: 0010:[<ffffffff8154fcf7>] skb_dequeue+0x47/0x70
      RSP: 0018:ffff880035c93db8  EFLAGS: 00010097
      RAX: 0000000000000246 RBX: ffff8800d2754b00 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 0000000000000202 RDI: ffff8800d254c084
      RBP: ffff880035c93dd0 R08: ffff880035c93cf0 R09: ffff8800d968f270
      R10: 0000000000000000 R11: 0000000000000293 R12: ffff8800d254c070
      R13: ffff8800d254c084 R14: ffff8800cd861240 R15: ffff880119b39720
      FS:  00007f37a969d740(0000) GS:ffff88011fc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000008 CR3: 00000000d4413000 CR4: 00000000000006f0
      Stack:
       ffff8800d254c000 ffff8800d254c070 ffff8800d254c2c0 ffff880035c93df8
       ffffffffa041a5b8 ffff8800cd844c80 ffffffffa04385a0 ffff8800cd844cb0
       ffff880035c93e18 ffffffff81546cef ffff8800d45fea00 0000000000000008
      Call Trace:
       [<ffffffffa041a5b8>] rxrpc_release+0x128/0x2e0 [af_rxrpc]
       [<ffffffff81546cef>] sock_release+0x1f/0x80
       [<ffffffff81546d62>] sock_close+0x12/0x20
       [<ffffffff811aaba1>] __fput+0xe1/0x230
       [<ffffffff811aad3e>] ____fput+0xe/0x10
       [<ffffffff810862cc>] task_work_run+0xbc/0xe0
       [<ffffffff8106a3be>] do_exit+0x2be/0xa10
       [<ffffffff8116dc47>] ? do_munmap+0x297/0x3b0
       [<ffffffff8106ab8f>] do_group_exit+0x3f/0xa0
       [<ffffffff8106ac04>] SyS_exit_group+0x14/0x20
       [<ffffffff8166b069>] system_call_fastpath+0x16/0x1b
      
      
      Signed-off-by: default avatarTim Smith <tim@electronghost.co.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      24a9981e
    • Alexey Khoroshilov's avatar
      RxRPC: do not unlock unheld spinlock in rxrpc_connect_exclusive() · 8f22ba61
      Alexey Khoroshilov authored
      
      If rx->conn is not NULL, rxrpc_connect_exclusive() does not
      acquire the transport's client lock, but it still releases it.
      
      The patch adds locking of the spinlock to this path.
      
      Found by Linux Driver Verification project (linuxtesting.org).
      
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      8f22ba61
    • Ilya Dryomov's avatar
      libceph: dout() is missing a newline · 0b4af2e8
      Ilya Dryomov authored
      
      Add a missing newline to a dout() in __reset_osd().
      
      Signed-off-by: default avatarIlya Dryomov <ilya.dryomov@inktank.com>
      0b4af2e8
    • Ilya Dryomov's avatar
      libceph: add ceph_kv{malloc,free}() and switch to them · eeb0bed5
      Ilya Dryomov authored
      
      Encapsulate kmalloc vs vmalloc memory allocation and freeing logic into
      two helpers, ceph_kvmalloc() and ceph_kvfree(), and switch to them.
      
      ceph_kvmalloc() kmalloc()'s a maximum of 8 pages, anything bigger is
      vmalloc()'ed with __GFP_HIGHMEM set.  This changes the existing
      behaviour:
      
      - for buffers (ceph_buffer_new()), from trying to kmalloc() everything
        and using vmalloc() just as a fallback
      
      - for messages (ceph_msg_new()), from going to vmalloc() for anything
        bigger than a page
      
      - for messages (ceph_msg_new()), from disallowing vmalloc() to use high
        memory
      
      Signed-off-by: default avatarIlya Dryomov <ilya.dryomov@inktank.com>
      Reviewed-by: default avatarSage Weil <sage@inktank.com>
      eeb0bed5
  6. Jan 24, 2014
  7. Jan 23, 2014
Loading