netdev - Re: ip_rcv_finish() NULL pointer kernel panic

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 26 Jan 2017 10:02:58 -0600 (CST)
From:   Roy Keene <lkml@...ene.org>
To:     Eric Dumazet <eric.dumazet@...il.com>
cc:     netdev@...r.kernel.org, netfilter-devel@...r.kernel.org
Subject: Re: ip_rcv_finish() NULL pointer kernel panic

> On Thu, 2017-01-26 at 09:32 -0600, Roy Keene wrote:
>> This bug appears to have existed for a long time:
>>
>>  	https://www.spinics.net/lists/netdev/msg222459.html
>>
>>  	http://www.kernelhub.org/?p=2&msg=823752
>>
>> Though possibly with different things not setting the "input" function
>> pointer in the "struct dst_entry".
>>
>> include/net/dst.h:
>>   496 static inline int dst_input(struct sk_buff *skb) {
>>   498         return skb_dst(skb)->input(skb);
>>   499 }
>>
>> Is there any reason not to check to see if this pointer is NULL before
>> blindly calling it ?
>
> Sure. It can not be NULL at this point.
>

It clearly can be NULL at this point, since there are kernel panics for 
15 years of this -- going all the way back to 2.2.20 !

https://lists.gt.net/linux/kernel/250077

It seems like it might actually be a good idea to do as Alex Bligh 
suggested all those years ago and I re-suggested now.

> Just look at the code in ip_rcv_finish() :
>
> It first make sure to get a valid dst.
>
> Something is broken, probably in bridge netfilter code.
>

I'll try poking around there.

> I suspect the dst here points to &br->fake_rtable, and this is not
> expected.
>
> br_drop_fake_rtable() should have been called somewhere ...
>

Thanks,
 	Roy Keene