tree 015da34815f13f67f04ec0336b771a7c1a7b14e2
parent 60cc43fc888428bb2f18f08997432d426a243338
author Kees Cook <keescook@chromium.org> 1524091980 -0700
committer Kees Cook <keescook@chromium.org> 1524099403 -0700

usercopy: split user-controlled slabs to separate caches

Some userspace APIs (e.g. ipc, seq_file) provide precise control over
the size of kernel kmallocs, which provides a trivial way to perform
heap overflow attacks where the attacker must control neighboring
allocations of a specific size. Instead, move these APIs into their own
cache so they cannot interfere with standard kmallocs. This is enabled
with CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC.

This would frustrate common methods of heap grooming. As an example
http://cyseclabs.com/blog/cve-2016-6187-heap-off-by-one-exploit
recognizes this common method, saying "the standard msgget()
technique". Having the separate caches doesn't strictly _stop_ some
attacks, but it changes the nature of what the attacker has to do.
Instead of having a universal way to groom the heap, they must
be forced into other paths, which may narrow the range of possible
methods. Generally speaking this can make a given attack impossible,
more expensive to develop, or less reliable.

This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY_SLABS
code in the last public patch of grsecurity/PaX based on my understanding
of the code. Changes or omissions from the original code are mine and
don't reflect the original grsecurity/PaX code.

Co-Developed-by: David Windsor <dave@nullcore.net>
Signed-off-by: Kees Cook <keescook@chromium.org>