linux-kernel - Re: [PATCH] lkdtm: fix maybe-uninitialized warning

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 26 Jul 2016 22:58:32 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Kees Cook <keescook@...omium.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] lkdtm: fix maybe-uninitialized warning

On Tuesday, July 26, 2016 8:21:37 AM CEST Kees Cook wrote:
> On Tue, Jul 26, 2016 at 5:28 AM, Arnd Bergmann <arnd@...db.de> wrote:
> > The do_usercopy_stack() function uses uninitialized stack data to initialize
> > more of the stack, which causes a warning in some configurations (ARM allmodconfig):
> >
> > drivers/misc/lkdtm_usercopy.c:52:15: warning: 'bad_stack' may be used uninitialized in this function [-Wmaybe-uninitialized]
> >
> > The warning gets reports by Mark Brown's build bot and looks correct (we are trying
> > to trick the compiler here, and sometimes the compiler notices), and I could reproduce
> > it with gcc-4.7 through gcc-5.3 but not gcc-6.1 for some reason.
> >
> > This changes the code to use the low byte of the address of the stack to initialize
> > the stack data, instead of using data from the stack itself, to avoid the warning.
> >
> > Signed-off-by: Arnd Bergmann <arnd@...db.de>
> > Fixes: a3dff71c1c88 ("lkdtm: split usercopy tests to separate file")
> 
> Acked-by: Kees Cook <keescook@...omium.org>
> 
> I thought I already sent this fix to Greg?

Possible. I mentioned the problem to you when it first showed up,
but noticed today that I didn't have a patch for it in my testing
tree (since I test with gcc-6.1, which doesn't show the bug).

> Maybe it got lost...

More likely that it's still in his backlog then.

	Arnd