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
| ||
|
Date: Wed, 18 Jun 2008 16:10:20 +1000 From: Nick Piggin <nickpiggin@...oo.com.au> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Andi Kleen <andi@...stfloor.org>, Bron Gondwana <brong@...tmail.fm>, 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>, Ingo Molnar <mingo@...e.hu> Subject: Re: BUG: mmapfile/writev spurious zero bytes (x86_64/not i386, bisected, reproducable) On Wednesday 18 June 2008 07:46, Linus Torvalds wrote: > On Tue, 17 Jun 2008, Andi Kleen wrote: > So the patch _fixes_ copy_from_user(), exactly because it says that even > if you've loaded 24 bytes, but you faulted on the fourth load, you've > still _copied_ exactly zero bytes, because you didn't actually store the > 24 bytes you loaded. Yes, the new filemap.c code does not require an exact byte count, but it won't work if there is an under-estimation of the number of bytes left to copy. The old filemap.c code actually also relies on the byte count in some cases, I can't remember off the top of my head, but I *think* it was a security measure to prevent uninitialized data leak. Most other cases of course only care about complete success or not, but there are others. filemap_xip, splice are a couple that pop up. Thanks for working that all out before I even read my email :) -- 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/
Powered by blists - more mailing lists