netdev - AW: AW: 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] [day] [month] [year] [list]

Date:   Tue, 7 Aug 2018 13:42:53 +0000
From:   Marcel Hellwig <mhellwig@...-group.com>
To:     'Eric Dumazet' <eric.dumazet@...il.com>,
        'David Laight' <David.Laight@...LAB.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: AW: AW: PROBLEM: Kernel Oops in UDP stack

>>
>> Well, this driver does not use NET_IP_ALIGN reservation, meaning IP header is not 4-byte aligned.
>>
>> No idea why mis-alignments are okay in IP layer, but not in UDP
>>
>> You could try to patch it to use netdev_alloc_skb_ip_align() instead of dev_alloc_skb()
> 
> Looks very promising! CPU runs for 3 hours and no panic so far. Let's hope it survives the weekend! *fingers crossed* The strange thing I don't understand is, why does the 3.5.7 kernel does not crash (or 4.17.12, yes I managed to run a recent kernel on our machine! \o/ )? It does not use netdev_alloc_skb_ip_align either[0][1], but one thing, that I noticed it, that there is a difference in /proc/iomem
> 
> 3.4.113
> # cat /proc/iomem
> 08000000-0801ffff : lpc-eth.0
> 31060000-31060fff : lpc-eth.0
> 40088000-4008801f : serial
> [...]
> 
> 3.5.7
> # cat /proc/iomem
> 20084000-20084fff : /ahb/apb/ssp@...84000
> 2008c000-2008cfff : /ahb/apb/ssp@...8c000
> 31000000-31000fff : /ahb/dma@...00000
> 40088000-4008801f : serial
> [...]
> 
> As you notice lpc-eth.0 (or 31060000.ethernet as it's called nowadays) is not listed, so my guess it is served by DMA?
> 
> May that the reason why it does not crash (Notice: 3.5.7 runs via device tree file)?
> 
> So just my thought: If I would disable dma (somehow) would the error still occur in today's kernel?

I think, that it is implicitly aligned today (I think!), so that's the reason why the oops does not occur anymore.

Our machines survived the 4 days now, so we are very confident, that this solved the problem for us!

Thank you very much, you all helped us a lot! 

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