netdev - [PATCH net-next 0/2] Address reference counting issues with sock_queue_err

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140910215837.23225.39149.stgit@ahduyck-bv4.jf.intel.com>
Date:	Wed, 10 Sep 2014 18:04:42 -0400
From:	Alexander Duyck <alexander.h.duyck@...el.com>
To:	netdev@...r.kernel.org, linux-wireless@...r.kernel.org
Cc:	johannes@...solutions.net, davem@...emloft.net,
	eric.dumazet@...il.com, linville@...driver.com
Subject: [PATCH net-next 0/2] Address reference counting issues with
 sock_queue_err_skb

After looking over the code for skb_clone_sk after some comments made by
Eric Dumazet I have come to the conclusion that skb_clone_sk is taking the
correct approach in how to handle the sk_refcnt when creating a buffer that
is eventually meant to be returned to the socket via the sock_queue_err_skb
function.

However upon review of other callers I found what I believe to be a
possible reference count issue in the path for handling "wifi ack" packets.
To address this I have applied the same logic that is currently in place so
that the sk_refcnt will be forced to stay at least 1, or we will not
provide an skb to return in the sk_error_queue.

---

Alexander Duyck (2):
      skb: Add documentation for skb_clone_sk
      mac80211: Resolve sk_refcnt/sk_wmem_alloc issue in wifi ack path

 net/core/skbuff.c |   18 ++++++++++++++++++
 net/mac80211/tx.c |   15 ++++-----------
 2 files changed, 22 insertions(+), 11 deletions(-)

-- 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html