linux-kernel - Re: bug in generic strncpy_from

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Feb 2013 08:08:15 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Gerald Schaefer <gerald.schaefer@...ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: bug in generic strncpy_from_user

On Tue, Feb 26, 2013 at 7:51 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> I think the problem is that we add the guard page *after* we do the
> normal "let's try to expand" logic.
>
> I'll take a look.

Ahh, no. The guard page logic happens later at the fault time. We do
this in two phases - first "find_extend_vma()" does what the name
claims, and then check_stack_guard_page() is done for the last-page
case from within do_anonymous_page() when we actually touch the last
page itself.

But that's actually fine. We can simply make "find_extend_vma()" do
the obvious "refuse to extend the vma all the way", because we will
later allow the guard page to extend downwards to "touch" the mapping,
but that uses separate logic. So the attached trivial patch seems to
make perfect sense:

It is totally untested, though.  Does it work for you (and we should
do the same thing for the grows-up case, obviously)?

         Linus

Download attachment "patch.diff" of type "application/octet-stream" (450 bytes)