linux-kernel - Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv

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:	Wed, 30 Dec 2015 08:26:55 -0500
From:	Eric Dumazet <edumazet@...gle.com>
To:	Jacob Siverskog <jacob@...nage.engineering>
Cc:	David Miller <davem@...emloft.net>,
	Rainer Weikusat <rweikusat@...ileactivedefense.com>,
	netdev <netdev@...r.kernel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
	Al Viro <viro@...iv.linux.org.uk>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

On Wed, Dec 30, 2015 at 6:14 AM, Jacob Siverskog
<jacob@...nage.engineering> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/