netdev - Re: Kernel Panics in the network 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]

Message-ID: <4B22BC1F.607@gmail.com>
Date:	Fri, 11 Dec 2009 22:39:43 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Kevin Constantine <kevin.constantine@...il.com>
CC:	netdev@...r.kernel.org
Subject: Re: Kernel Panics in the network stack

Le 11/12/2009 22:09, Kevin Constantine a écrit :
> Hey Everyone-
> 
> I've been playing with an ARM based linuxstamp
> http://opencircuits.com/Linuxstamp, and I've been seeing kernel panics
> with both 2.6.28.3, and 2.6.30 within an hour or so of turning the
> linuxstamp on.  The stack traces always seem to point at functions
> related to networking.  I've pasted a couple of the crash outputs below.
>  The linuxstamp isn't typically doing anything when the crashes occur,
> in fact it'll crash even if I haven't logged in.
> 
> If I ifconfig the interface down, the linuxstamp stays up indefinitely.
>  Any pointers in one direction or another would be much appreciated.
> 
> I'm not sure if this is the right audience to help out or if the arm
> lists might be better.  But in any event, any help would be really
> appreciated.
> 
> 
> linuxstamp login: Unable to handle kernel paging request at virtual
> address 183cb7b0
> pgd = c0004000
> [183cb7b0] *pgd=00000000
> Internal error: Oops: 0 [#1] PREEMPT
> Modules linked in:
> CPU: 0    Not tainted  (2.6.30-00002-g0148992 #13)
> PC is at 0x183cb7b0
> LR is at __udp4_lib_rcv+0x43c/0x72c

Could you disassemble your vmlinux file, __udp4_lib_rcv function around LR
<c024ff4c>, to see which function was called ? This function then called 
a wrong pointer (0x183cb7b0 not a kernel pointer)

Maybe a kernel stack corruption, or bad ram, ...
--
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