linux-kernel - Re: [PATCH] net: sk == 0xffffffff fix

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: <1389889754.31367.406.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Thu, 16 Jan 2014 08:29:14 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Andrzej Pietrasiewicz <andrzej.p@...sung.com>
Cc:	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Felipe Balbi <balbi@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	"David S. Miller" <davem@...emloft.net>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	James Morris <jmorris@...ei.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] net: sk == 0xffffffff fix - not for commit

On Thu, 2014-01-16 at 16:21 +0100, Andrzej Pietrasiewicz wrote:
> W dniu 10.12.2013 15:25, Eric Dumazet pisze:
> > On Tue, 2013-12-10 at 07:55 +0100, Andrzej Pietrasiewicz wrote:
> >> W dniu 09.12.2013 16:31, Eric Dumazet pisze:
> >>> On Mon, 2013-12-09 at 12:47 +0100, Andrzej Pietrasiewicz wrote:
> >>>> NOT FOR COMMITTING TO MAINLINE.
> >>>>
> >>>> With g_ether loaded the sk occasionally becomes 0xffffffff.
> >>>> It happens usually after transferring few hundreds of kilobytes to few
> >>>> tens of megabytes. If sk is 0xffffffff then dereferencing it causes
> >>>> kernel panic.
> >>>>
> >>>> This is a *workaround*. I don't know enough net code to understand the core
> >>>> of the problem. However, with this patch applied the problems are gone,
> >>>> or at least pushed farther away.
> >>>
> >>> Is it happening on SMP or UP ?
> >>
> >> UP build, S5PC110
> >
> > OK
> >
> > I believe you need additional debugging to track the exact moment
> > 0xffffffff is fed to 'sk'
> >
> > It looks like a very strange bug, involving a problem in some assembly
> > helper, register save/restore, compiler bug or stack corruption or
> > something.
> >
> 
> I started with adding WARN_ON(sk == 0xffffffff); just before return in
> __inet_lookup_established(), and the problem was gone. So this looks
> very strange, like a toolchain problem.

Or a timing issue. Adding a WARN_ON() adds extra instructions and might
really change the assembly output.

> 
> I used gcc-linaro-arm-linux-gnueabihf-4.8-2013.05.
> 
> If I change the toolchain to
> 
> gcc-linaro-arm-linux-gnueabihf-4.7-2013.04-20130415
> 
> the problem seems to have gone away.

Its totally possible some barrier was not properly handled by the
compiler. You could disassemble the function on both toolchains and
try to spot the issue.



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