netdev - Re: mac80211 truesize bugs

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1209815533.3987.21.camel@johannes.berg>
Date:	Sat, 03 May 2008 13:52:13 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	David Miller <davem@...emloft.net>
Cc:	herbert@...dor.apana.org.au, mb@...sch.de, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: mac80211 truesize bugs


> We can't update skb->truesize during arbitray skb->data reallocations,
> because it could corrupt the socket accounting.
> 
> On the other hand, if we provide ways for users to subvert the socket
> buffer limits, we might as well not try to limit anything.

Why don't we update the socket allocation when doing pskb_expand_head()?
Sure, it could become negative, but is that so bad?

> Take a look at some ethernet drivers that implement TSO in a way that
> requires munging the IP headers for whatever reason.  If they need to
> COW the packet data in order to modify it, they always do this with
> pskb_expand_head(skb, 0, 0, GFP_*) exactly so that they don't modify
> the SKB data size, and exactly so that the skb->truesize value stays
> accurate.

We need more space though. Should we then just increase the built-in
headroom?

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)