[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWGp4wARvxNopt7ZFUfDMssAw9oS8fuwROv76EdQe_OQA@mail.gmail.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
