Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932124AbbL3N1B (ORCPT ); Wed, 30 Dec 2015 08:27:01 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:33253 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755217AbbL3N05 (ORCPT ); Wed, 30 Dec 2015 08:26:57 -0500 MIME-Version: 1.0 In-Reply-To: References: <1451416224-15871-1-git-send-email-jacob@teenage.engineering> <87y4cdyrbn.fsf@doppelsaurus.mobileactivedefense.com> <20151229.150843.2021692616139434395.davem@davemloft.net> Date: Wed, 30 Dec 2015 08:26:55 -0500 Message-ID: Subject: Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram From: Eric Dumazet To: Jacob Siverskog Cc: David Miller , Rainer Weikusat , netdev , Herbert Xu , Konstantin Khlebnikov , Al Viro , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1530 Lines: 42 On Wed, Dec 30, 2015 at 6:14 AM, Jacob Siverskog 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/