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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 02 May 2008 16:33:34 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	johannes@...solutions.net
Cc:	herbert@...dor.apana.org.au, mb@...sch.de, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: mac80211 truesize bugs

From: Johannes Berg <johannes@...solutions.net>
Date: Fri, 02 May 2008 22:38:51 +0200

> I'm confused. The area should be used say with encryption when it's
> actually necessary. Maybe there's always enough headroom for some
> reason now?

That's possible.

There are paths, that, although they could take advantage of the
fact that all of the non-header packet data is going to come from
pages, they don't and allocate a full MTU skb->data area anyways.

> On another note, why is this truesize mismatch a bug anyway? I mean, the
> field could just be called "socket_charged_size" and simply be required
> to have the same value throughout the skb lifetime, the slight mismatch
> between charged bytes and actually used bytes wouldn't usually matter
> too much, would it?

Sure the name could change, but the problem wouldn't.

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.

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.

Try to find out exactly what's going wrong here, you seem to be
close.  Once we know the precise issue we can talk about real
changes to make this easier to cope with and debug in the future.
--
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