netdev - Re: Null pointer dereference in UDP4 core on AVR32 ATNGW100

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] [day] [month] [year] [list]
Message-ID: <CAHp75VdLE9aJO1EcBFmdK00f1D+jzV240jNV_0Ka1xMQ6gmkSw@mail.gmail.com>
Date:	Fri, 31 Jul 2015 16:51:17 +0300
From:	Andy Shevchenko <andy.shevchenko@...il.com>
To:	Eric Dumazet <edumazet@...gle.com>
Cc:	netdev <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	David Held <drheld@...gle.com>,
	Hans-Christian Egtvedt <egtvedt@...fundet.no>
Subject: Re: Null pointer dereference in UDP4 core on AVR32 ATNGW100

On Fri, Jul 31, 2015 at 4:49 PM, Eric Dumazet <edumazet@...gle.com> wrote:
> How much memory you have on this host ?
>
> dmesg | grep hash
>
>

# dmesg | grep hash
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
futex hash table entries: 16 (order: -5, 192 bytes)


> On Fri, Jul 31, 2015 at 3:45 PM, Andy Shevchenko
> <andy.shevchenko@...il.com> wrote:
>> On Fri, Jul 31, 2015 at 4:25 PM, Andy Shevchenko
>> <andy.shevchenko@...il.com> wrote:
>>> Hi!
>>>
>>> Got few weeks ago an old AVR32 board (ATNGW100).
>>> It has ethernet cards supported by macb driver.
>>>
>>> Bring it mostly back to work with recent kernel from linux-next. Now,
>>> when I start networking on it, I got in few seconds kernel panic.
>>
>> Seems the hack fixes this (still playing with network connected).
>>
>> # uname -a
>> Linux buildroot 4.2.0-rc4-next-20150731+ #164 Fri Jul 31 16:37:20 EEST
>> 2015 avr32 GNU/Linux
>>
>>
>> --- a/net/ipv4/udp.c
>> +++ b/net/ipv4/udp.c
>> @@ -1665,6 +1665,10 @@ static int __udp4_lib_mcast_deliver(struct net
>> *net, struct sk_buff *skb,
>>         unsigned int hash2 = 0, hash2_any = 0, use_hash2 = (hslot->count > 10);
>>         bool inner_flushed = false;
>>
>> +#ifdef CONFIG_AVR32
>> +       use_hash2 = 0;
>> +#endif
>> +
>>         if (use_hash2) {
>>                 hash2_any = udp4_portaddr_hash(net, htonl(INADDR_ANY), hnum) &
>>                             udp_table.mask;
>>
>>
>>
>>>
>>> Unable to handle kernel NULL pointer dereference at virtual address 00000000
>>> ptbr = 91e42000 pgd = 91e4b000
>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>> FRAME_POINTER chip: 0x01f:0x1e82 rev 2
>>> Modules linked in:
>>> CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0-rc4-next-20150729+ #102
>>> task: 903532dc ti: 90350000 task.ti: 90350000
>>> PC is at __udp4_lib_rcv+0x300/0x660
>>> LR is at 0x15da8a2f
>>> pc : [<90233a84>]    lr : [<15da8a2f>]    Not tainted
>>> 0sp : 90351b5c  r12: 00000000  r11: 91cd4450
>>> r10: 00000000  r9 : 0000004c  r8 : 00000000
>>> r7 : 90351c80  r6 : 91db5c80  r5 : 91e4e540  r4 : 11f6a114
>>> r3 : 00000000  r2 : 91e6b224  r1 : 0000008a  r0 : 00000000
>>> Flags: qvnZc
>>> Mode bits: hjmde....g
>>> CPU Mode: Interrupt level 0
>>> Stack: (0x90351b5c to 0x90352000)
>>> …
>>> Call trace:
>>> [<90233df0>] udp_rcv+0xc/0x14
>>> [<90215220>] ip_local_deliver_finish+0xac/0x15c
>>> [<902150ca>] ip_local_deliver+0x76/0x84
>>> [<90214d32>] ip_rcv_finish+0x23a/0x250
>>> [<90215004>] ip_rcv+0x2bc/0x30c
>>> [<901f5ee4>] __netif_receive_skb_core+0x548/0x570
>>> [<901f5f52>] __netif_receive_skb+0x46/0x50
>>> [<901f5f8e>] netif_receive_skb_internal+0x32/0x3c
>>> [<901f5fa0>] netif_receive_skb_sk+0x8/0xc
>>> [<901cf358>] macb_rx+0x1b0/0x1d8
>>> [<901cf4d8>] macb_poll+0x38/0xa4
>>> [<901faf9c>] net_rx_action+0x84/0x1b4
>>> [<90021e46>] __do_softirq+0x5a/0x150
>>> [<90021f86>] irq_exit+0x26/0x58
>>> [<9001a520>] do_IRQ+0x34/0x44
>>> [<90019428>] irq_level0+0x18/0x5c
>>> [<900355a4>] default_idle_call+0x1c/0x20
>>> [<9003563e>] cpu_startup_entry+0x66/0xa8
>>> [<902a16a4>] rest_init+0x48/0x70
>>> [<900007fc>] start_kernel+0x290/0x2dc
>>>
>>> Long time bisecting and reading assembly points to the
>>>
>>> commit 2dc41cff7545d55c6294525c811594576f8e119c
>>> Author: David Held <drheld@...gle.com>
>>> Date:   Tue Jul 15 23:28:32 2014 -0400
>>>
>>>     udp: Use hash2 for long hash1 chains in __udp*_lib_mcast_deliver.
>>>
>>> I don't know yet neither the package exactly makes this (tried to
>>> debug print, but bug disappears) nor should be network card driver
>>> fixed, or even compiler / binutils problems (using it from buildroot,
>>> which is gcc 4.2.2). Would like to hear opinions what the root cause
>>> might be and what ways we have to fix it. I'm also wondering if any
>>> other architecture with same network card has the issue.
>>>
>>> P.S.
>>> Since buildroot is not supporting anymore avr32 I use the version just
>>> before this removal. (Nicolas, does Atmel care about that?)
>>>
>>> --
>>> With Best Regards,
>>> Andy Shevchenko
>>
>>
>>
>> --
>> With Best Regards,
>> Andy Shevchenko



-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html