netdev - Re: [PATCH] [NET] warn when accounting an skb that already has a destructor

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]

Date:	Mon, 05 May 2008 09:31:15 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] [NET] warn when accounting an skb that already has a
	destructor

On Mon, 2008-05-05 at 00:20 -0700, David Miller wrote:
> From: Johannes Berg <johannes@...solutions.net>
> Date: Sun, 04 May 2008 20:32:20 +0200
> 
> > This makes the networking layer warn when something tries to
> > charge an skb to a socket that already is charged to another
> > socket (or has a destructor from somewhere else.)
> > 
> > Signed-off-by: Johannes Berg <johannes@...solutions.net>
> 
> I completely agree that this a correct assertion, that
> absolutely should never happen in the current tree.
> 
> But if we are going to do this, I'm pretty sure we'll
> need to uninline these two routines.
> 
> I'll leave it up to you, if you think it's still worthwhile
> with the uninlining, please resubmit :-)

Given that it's a corner case and no regular net drivers would ever want
to do something that could possibly cause this condition to be true,
it's probably not worth it either way. Even mac80211 doesn't run into
it, although it might have helped a bit to remember to add skb_orphan()
to the re-injection.

If we decide to uninline those functions for another reason (used too
much, code size, ...) then we can still do that.

johannes

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