* [PATCH] packet: fix potential use after free
@ 2014-04-10 1:22 Eric Dumazet
2014-04-10 8:19 ` Daniel Borkmann
0 siblings, 1 reply; 5+ messages in thread
From: Eric Dumazet @ 2014-04-10 1:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Xi Wang
From: Eric Dumazet <edumazet@google.com>
As soon skb is queued into sk_receive_queue, it can be consumed,
so its racy to access skb->len.
Given that sk_data_ready() / sock_def_readable() don't really care, just
use 0 instead of skb->len
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Xi Wang <xii@google.com>
---
net/packet/af_packet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 72e0c71fb01d..373d557e22ee 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1848,7 +1848,8 @@ static int packet_rcv(struct sk_buff *skb, struct net_device *dev,
skb->dropcount = atomic_read(&sk->sk_drops);
__skb_queue_tail(&sk->sk_receive_queue, skb);
spin_unlock(&sk->sk_receive_queue.lock);
- sk->sk_data_ready(sk, skb->len);
+ /* Remember: we can not reference skb after this point */
+ sk->sk_data_ready(sk, 0);
return 0;
drop_n_acct:
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] packet: fix potential use after free
2014-04-10 1:22 [PATCH] packet: fix potential use after free Eric Dumazet
@ 2014-04-10 8:19 ` Daniel Borkmann
2014-04-10 15:06 ` Eric Dumazet
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Borkmann @ 2014-04-10 8:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Xi Wang
On 04/10/2014 03:22 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> As soon skb is queued into sk_receive_queue, it can be consumed,
> so its racy to access skb->len.
>
> Given that sk_data_ready() / sock_def_readable() don't really care, just
> use 0 instead of skb->len
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Xi Wang <xii@google.com>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Seems to be there since pre 2005 ...
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] packet: fix potential use after free
2014-04-10 8:19 ` Daniel Borkmann
@ 2014-04-10 15:06 ` Eric Dumazet
2014-04-11 19:59 ` David Miller
0 siblings, 1 reply; 5+ messages in thread
From: Eric Dumazet @ 2014-04-10 15:06 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: David Miller, netdev, Xi Wang
On Thu, 2014-04-10 at 10:19 +0200, Daniel Borkmann wrote:
> On 04/10/2014 03:22 AM, Eric Dumazet wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > As soon skb is queued into sk_receive_queue, it can be consumed,
> > so its racy to access skb->len.
> >
> > Given that sk_data_ready() / sock_def_readable() don't really care, just
> > use 0 instead of skb->len
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Xi Wang <xii@google.com>
>
> Acked-by: Daniel Borkmann <dborkman@redhat.com>
>
> Seems to be there since pre 2005 ...
Yeah, and many other places have the same error, a full audit is
probably needed.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] packet: fix potential use after free
2014-04-10 15:06 ` Eric Dumazet
@ 2014-04-11 19:59 ` David Miller
2014-04-11 23:37 ` Daniel Borkmann
0 siblings, 1 reply; 5+ messages in thread
From: David Miller @ 2014-04-11 19:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: dborkman, netdev, xii
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 10 Apr 2014 08:06:58 -0700
> On Thu, 2014-04-10 at 10:19 +0200, Daniel Borkmann wrote:
>> On 04/10/2014 03:22 AM, Eric Dumazet wrote:
>> > From: Eric Dumazet <edumazet@google.com>
>> >
>> > As soon skb is queued into sk_receive_queue, it can be consumed,
>> > so its racy to access skb->len.
>> >
>> > Given that sk_data_ready() / sock_def_readable() don't really care, just
>> > use 0 instead of skb->len
>> >
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>> > Cc: Xi Wang <xii@google.com>
>>
>> Acked-by: Daniel Borkmann <dborkman@redhat.com>
>>
>> Seems to be there since pre 2005 ...
>
> Yeah, and many other places have the same error, a full audit is
> probably needed.
Not only sock_def_readable(), but all implementations of this callback absolutely
do not care about the length argument.
I'm working on a patch to kill the argument completely.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] packet: fix potential use after free
2014-04-11 19:59 ` David Miller
@ 2014-04-11 23:37 ` Daniel Borkmann
0 siblings, 0 replies; 5+ messages in thread
From: Daniel Borkmann @ 2014-04-11 23:37 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, xii
On 04/11/2014 09:59 PM, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 10 Apr 2014 08:06:58 -0700
>
>> On Thu, 2014-04-10 at 10:19 +0200, Daniel Borkmann wrote:
>>> On 04/10/2014 03:22 AM, Eric Dumazet wrote:
>>>> From: Eric Dumazet <edumazet@google.com>
>>>>
>>>> As soon skb is queued into sk_receive_queue, it can be consumed,
>>>> so its racy to access skb->len.
>>>>
>>>> Given that sk_data_ready() / sock_def_readable() don't really care, just
>>>> use 0 instead of skb->len
>>>>
>>>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>>>> Cc: Xi Wang <xii@google.com>
>>>
>>> Acked-by: Daniel Borkmann <dborkman@redhat.com>
>>>
>>> Seems to be there since pre 2005 ...
>>
>> Yeah, and many other places have the same error, a full audit is
>> probably needed.
>
> Not only sock_def_readable(), but all implementations of this callback absolutely
> do not care about the length argument.
>
> I'm working on a patch to kill the argument completely.
Sounds good! Seen you've already pushed that, thanks!
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-04-11 23:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-10 1:22 [PATCH] packet: fix potential use after free Eric Dumazet
2014-04-10 8:19 ` Daniel Borkmann
2014-04-10 15:06 ` Eric Dumazet
2014-04-11 19:59 ` David Miller
2014-04-11 23:37 ` Daniel Borkmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).