linux-kernel - Re: BUG: mmapfile/writev spurious zero bytes (x86

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]

Message-ID: <alpine.LFD.1.10.0806171331460.2908@woody.linux-foundation.org>
Date:	Tue, 17 Jun 2008 13:41:41 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Bron Gondwana <brong@...tmail.fm>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Nick Piggin <npiggin@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rob Mueller <robm@...tmail.fm>,
	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: BUG: mmapfile/writev spurious zero bytes (x86_64/not i386,
 bisected, reproducable)

On Tue, 17 Jun 2008, Linus Torvalds wrote:
> 
> I actually am starting to think that the bug is in 
> __copy_to_user_inatomic_nocache().

Confirmed.

The uncached user copies are totally broken. The number of bytes left 
uncopied is simply wrong, because of how it does that unrolled loop and 
doesn't account for the fact that just doing loads does not actually 
increase the number of bytes copied at all.

So because the "copy_to_user_inatomic()" logic cares _deeply_ about how 
many bytes were actually copied, when the copy count is wrong, the code 
ends up thinking that it copied more bytes than it actually did, resulting 
in the corruption in the page cache.

Nasty.

That whole file is a mess. Sadly, so is the regular "copy_user_64.S" too 
(it has the same totally broken comment, too!), this is not just the 
uncached version.

And the only reason that it only shows up with the uncached version in 
_practice_ is that the routine that uses the x86 string instructions (ie 
the "rep movsq" in copy_user_generic_string) actually gets this all right. 

So the bug is hidden in that case - which is most CPU's out there (all 
CPU's that have X86_FEATURE_REP_GOOD set).

I don't think that code is reasonably salvageable. Damn. 

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