netdev - AW: PROBLEM: Kernel Oops in UDP stack

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, 1 Aug 2018 05:55:20 +0000
From:   Marcel Hellwig <mhellwig@...-group.com>
To:     'Eric Dumazet' <eric.dumazet@...il.com>,
        "'davem@...emloft.net'" <davem@...emloft.net>,
        "'kuznet@....inr.ac.ru'" <kuznet@....inr.ac.ru>,
        "'yoshfuji@...ux-ipv6.org'" <yoshfuji@...ux-ipv6.org>,
        "'andrew@...n.ch'" <andrew@...n.ch>
CC:     "'netdev@...r.kernel.org'" <netdev@...r.kernel.org>,
        "'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
        "Matthias Wystrik" <mwystrik@...-group.com>
Subject: AW: PROBLEM: Kernel Oops in UDP stack

On Tue, Jul 31, 2018 at 15:36:05PM +0000 Andrew Lunn wrote:

> Is this mainline 3.4.113, or LPC version?
Mainline, afaik there is no newer version of the lpc kernel and the lpc driver are upstream since 3.4 (hence the 3.4.113 kernel version we tried).

> How much work is involved in testing a newer kernel. You are not going to get too much help from the community with such an old kernel. If you can reproduce it with a modern day kernel, then people are more likely to help.

We haven't tried any newer version, because DTS is mandatory since 3.5 afaik? We hadn't the time to look into, although it looks pretty straight forward.

>> Kernel oops:
>> [ 1125.090000] Unable to handle kernel paging request at virtual 
>> address c14fe63a [ 1125.100000] pgd = c14d8000 [ 1125.100000] 
>> [c14fe63a] *pgd=8140041e(bad) [ 1125.100000] Internal error: Oops: 1 
>> [#1] PREEMPT ARM [ 1125.100000] Modules linked in:
>> [ 1125.100000] CPU: 0    Not tainted  (3.4.113.7 #1)
>> [ 1125.100000] PC is at udp_recvmsg+0x284/0x33c [ 1125.100000] LR is 
>> at 0x0
> LR == 0 is suspicious. It should contain the return address, inet_recvmsg+0x38/0x4c. That is assuming the calling convention is the same for this old kernel as todays kernels on ARM.

I will do a little debugging why LR is 0 here. Maybe that's the clue.

> Could you produce net/ipv4/udp.lst for this exact kernel build?

Sure: https://gist.github.com/hellow554/6b11c6c0827d5db80a7e66f71f5636ff#file-net_uipv4_udp-lst

> Any idea how you could get file:line information ?
> ( like : udp_setsockopt+0x62/0xa0 net/ipv4/udp.c:2502 )

[<c0228adc>] (udp_recvmsg+0x284/0x33c) from [<c02306e0>] (inet_recvmsg+0x38/0x4c): net/ipv4/udp.c:1234
[<c02306e0>] (inet_recvmsg+0x38/0x4c) from [<c01d2c38>] (sock_recvmsg+0xa8/0xcc): include/linux/file.h:25
[<c01d2c38>] (sock_recvmsg+0xa8/0xcc) from [<c01d3fac>] (___sys_recvmsg.part.4+0xe0/0x1bc): net/socket.c:751
[<c01d3fac>] (___sys_recvmsg.part.4+0xe0/0x1bc) from [<c01d4fbc>] (__sys_recvmsg+0x50/0x80): net/socket.c:2193
[<c01d4fbc>] (__sys_recvmsg+0x50/0x80) from [<c000dfe0>] (ret_fast_syscall+0x0/0x2c): include/linux/file.h:25 (from arch/arm/kernel/entry-common.S:34)

https://elixir.bootlin.com/linux/v3.4.113/source :)


Many thanks for the answer, I hope I could answer your questions.


Mit freundlichen Grüßen / With kind regards

Marcel Hellwig
B. Sc. Informatik
Entwickler

m-u-t GmbH
Am Marienhof 2
22880 Wedel
Germany

Phone:	+49 4103 9308 - 474
Fax:  	+49 4103 9308 - 99
mhellwig@...-group.com

www.mut-group.com

Geschäftsführer (Managing Director): Fabian Peters
Amtsgericht Pinneberg (Commercial Register No.): HRB 10304 PI
USt-IdNr. (VAT-No.): DE228275390
WEEE-Reg-Nr.: DE 72271808