Date: Sun, 25 Jun 2017 20:49:43 -0700 From: Andy Lutomirski <luto@...nel.org> To: oss security list <oss-security@...ts.openwall.com> Subject: Can someone explain all the CONFIG_VMAP_STACK CVEs lately? As the author of the CONFIG_VMAP_STACK patches, I'm a bit confused here. There have been quite a few bugs in which some code passes a stack buffer to either sg_set_buf(), etc. or to the usb core. The former seem to all be crypto users. As I understand it, the supposed vulnerability is that, if you can force the buffer to span a page boundary, the kernel or device will instead hit the physical page following the the first page of the buffer, which is likely to be the wrong page. This causes corruption and maybe code execution. Naively, this failure mode occurs because __pa (or virt_to_phys() or virt_to_page() or whatever interface gets used) will return the PA of the *beginning* of the buffer, but the next virtual page may not be the next physical page. But this makes no sense -- __pa and friends don't have that effect when called on addresses in vmap space. So I tried to refresh my memory of what actually happened. (I looked into this when I wrote CONFIG_VMAP_STACK.) __pa() and friends return garbage when called on a vmap address. (I think it's likely to be a totally bogus PA that won't even correspond to a real physical page of memory.) The tricky but is that it's *invertable* garbage. When these buffers are passed to synchronous crypto APIs, the crypto core calls sg_virt(), which inverts the transformation and returns a valid virtual address of the page. But this is the original VA and points to the vmap space where the buffer is genuinely contiguous. IOW, for most synchronous crypto, using sg_set_buf() on a stack address is utterly bogus, but it works correctly. Ick. I haven't checked what USB does, but I suspect it's a wildly out-of-bounds DMA transfer that's more likely to result in a straight-up abort than easily exploitable corruption. So could someone all these CVEs, please? --Andy
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ