netdev - Re: L2TP: skb truesize bug in recent kernels

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: <20080514.031256.180455080.davem@davemloft.net>
Date:	Wed, 14 May 2008 03:12:56 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jchapman@...alix.com
Cc:	netdev@...r.kernel.org
Subject: Re: L2TP: skb truesize bug in recent kernels

From: James Chapman <jchapman@...alix.com>
Date: Wed, 14 May 2008 11:07:16 +0100

> The pppol2tp driver uses skb_cow_head() to make headroom for IP, UDP, 
> L2TP and PPP headers. As GRE is being used, it is more likely that there 
> will be insufficient headroom. Does the pppol2tp driver need to adjust 
> truesize if pskb_expand_head() is called?
> 
> I tried the following hack which stopped the skb truesize bug but caused 
> a kernel assert when the socket was closed:
> 
> KERN: assertion (!atomic_read(&sk->sk_wmem_alloc)) failed at 
> net/ipv4/af_inet.c (155)

You can't adjust the truesize when there is a socket associated
with the SKB.

We just had a weeklong thread on this list about these issues
wrt. the wireless stack :-)

skb->truesize records how much memory was charged to the assosicated
socket, so when the socket is freed, the destructor goes

	atomic_dec(&sk->sk_{r,w}mem_alloc, skb->truesize);

so if you increase truesize, the counter will be decremented
more than it was initially incremented.

You cannot change the size of the packet substantially when there is a
socket associated with it, because this makes the truesize inaccurate,
and thus provides a vector for a user's socket to use up more memory
than we were originally going to let it use based upon it's send and
receive buffer limits.
--
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