Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

[Eric Dumazet]

On Wed, Dec 30, 2015 at 6:14 AM, Jacob Siverskog
<jacob@xxxxxxxxxxxxxxxxxxx> wrote:

> Ok. Thanks for your feedback. How do you believe the issue could be
> solved? Investigating it gives:
>
> static inline void __skb_unlink(struct sk_buff *skb, struct sk_buff_head *list)
> {
> struct sk_buff *next, *prev;
>
> list->qlen--;
>      51c: e2433001 sub r3, r3, #1
>      520: e58b3074 str r3, [fp, #116] ; 0x74
> next   = skb->next;
> prev   = skb->prev;
>      524: e894000c ldm r4, {r2, r3}
> skb->next  = skb->prev = NULL;
>      528: e5841000 str r1, [r4]
>      52c: e5841004 str r1, [r4, #4]
> next->prev = prev;
>      530: e5823004 str r3, [r2, #4]                          <--
> trapping instruction (r2 NULL)
>
> Register contents:
> r7 : c58cfe1c  r6 : c06351d0  r5 : c77810ac  r4 : c583eac0
> r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 20000013
>
> If I understand this correctly, then r4 = skb, r2 = next, r3 = prev.
>
> Should there be a check for this in __skb_try_recv_datagram?

At this point corruption already happened.
We can not possibly detect every possible corruption caused by bugs
elsewhere in the kernel and just 'recover' at this point.
We must indeed find the root cause and fix it, instead of trying to hide it.

How often can you trigger this bug ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/