From: Herbert Xu
Date: Tue, 4 Aug 2015 15:42:47 +0800
> The commit 738ac1ebb96d02e0d23bc320302a6ea94c612dec ("net: Clone
> skb before setting peeked flag") introduced a use-after-free bug
> in skb_recv_datagram. This is because skb_set_peeked may create
> a new skb and free the existing one. As
On 04.08.2015 10:42, Herbert Xu wrote:
Brenden Blanco wrote:
[ 318.244596] BUG: unable to handle kernel NULL pointer dereference
at 008e
[ 318.245182] IP: [] __skb_recv_datagram+0xbc/0x5a0
Replying to myself, and adding commit interested parties...
I went through the git log fo
On Tue, Aug 04, 2015 at 08:30:23AM -0700, Brenden Blanco wrote:
>
> This patch holds good in my testing. Thanks!
Thanks for testing. Let's add a tag for patchwork:
Tested-by: Brenden Blanco
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.a
> The commit 738ac1ebb96d02e0d23bc320302a6ea94c612dec ("net: Clone
> skb before setting peeked flag") introduced a use-after-free bug
> in skb_recv_datagram. This is because skb_set_peeked may create
> a new skb and free the existing one. As it stands the caller will
> continue to use the old fre
David Laight wrote:
>
> In that case, what happens to the receive queue when skb_clone()
> takes a copy of the skb - freeing the original one?
The new skb is inserted into the recv queue and replacing the
existing skb.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key
From: Herbert Xu
> Sent: 04 August 2015 10:21
> On Tue, Aug 04, 2015 at 09:15:13AM +, David Laight wrote:
> >
> > You've introduced a memory leak if skb_clone() fails.
>
> No I have not.
>
> > > nskb = skb_clone(skb, GFP_ATOMIC);
> > > if (!nskb)
> > > - return -ENOMEM;
> > > +
On Tue, Aug 04, 2015 at 09:15:13AM +, David Laight wrote:
>
> You've introduced a memory leak if skb_clone() fails.
No I have not.
> > nskb = skb_clone(skb, GFP_ATOMIC);
> > if (!nskb)
> > - return -ENOMEM;
> > + return ERR_PTR(-ENOMEM);
>
> Here the original skb
From: Herbert Xu
> Sent: 04 August 2015 08:43
> Brenden Blanco wrote:
> >> [ 318.244596] BUG: unable to handle kernel NULL pointer dereference
> >> at 008e
> >> [ 318.245182] IP: [] __skb_recv_datagram+0xbc/0x5a0
> >
> > Replying to myself, and adding commit interested parties...
> >
Brenden Blanco wrote:
>> [ 318.244596] BUG: unable to handle kernel NULL pointer dereference
>> at 008e
>> [ 318.245182] IP: [] __skb_recv_datagram+0xbc/0x5a0
>
> Replying to myself, and adding commit interested parties...
>
> I went through the git log for the function in question