linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VdG5Ys09pmc1Qo1EHSRr1gYdLv--9NtECB_VUo5d9+USg@mail.gmail.com>
Date:	Fri, 31 Jul 2015 16:25:44 +0300
From:	Andy Shevchenko <andy.shevchenko@...il.com>
To:	netdev <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Eric Dumazet <edumazet@...gle.com>,
	David Held <drheld@...gle.com>,
	Hans-Christian Egtvedt <egtvedt@...fundet.no>
Subject: Null pointer dereference in UDP4 core on AVR32 ATNGW100

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.

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
--
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/