| 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: Fri, 6 Mar 2009 22:55:25 +0000 From: Russell King - ARM Linux <linux@....linux.org.uk> To: Steven Walter <stevenrwalter@...il.com> Cc: linux-arm-kernel@...ts.arm.linux.org.uk, linux-kernel@...r.kernel.org Subject: Re: cache aliasing in dup_mmap On Fri, Mar 06, 2009 at 05:26:24PM -0500, Steven Walter wrote: > I've been tracking down an instance of userspace data corruption, and I > believe I have found a window during fork where data can be lost. The > corruption is occurring on an ARMv5 system with VIVT caches. Here's the > scenario in question. Thread A is forking, Thread B is running in > userspace: With VIVT caches, you're missing a few things here: > Thread A: flush_cache_mm (dup_mmap) -- cache written back and invalidated > Thread B: writes to a page in the above mm -- cache written back and invalidated > Thread A: pte_wrprotect the above page (copy_one_pte) -- cache written back and invalidated > Thread B: writes to the same page again > > During thread B's second write, he'll take a fault and enter the do_wp_page > case. We'll end up calling copy_page, which notably uses the kernel virtual > addresses for the old and new pages. This means that the new page does not > necessarily have the data from the first write. Given the additional flushing I've mentioned above, where could the problem be? -- 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