crypto: Kernel memory overwrite attempt detected to spans multiple pages

Kees Cook keescook at chromium.org
Wed Apr 10 21:57:46 UTC 2019


On Wed, Apr 10, 2019 at 12:07 PM Eric Biggers <ebiggers at kernel.org> wrote:
> That didn't answer my question.  My question is what is the purpose of this?  If
> there was actual buffer overflow when __GFP_COMP isn't specified that would make
> perfect sense, but AFAICS there isn't.  So why does hardened usercopy consider
> it broken when __GFP_COMP isn't specified?

The goal of CONFIG_HARDENED_USERCOPY_PAGESPAN was to detect copies
across page boundaries in memory allocated by the page allocator.
There appear to be enough cases of allocations that span pages but do
not mark them with __GFP_COMP, so this logic hasn't proven useful in
the real world (which is why no one should use the ..._PAGESPAN config
in production). I'd like to get the kernel to the point where hardened
usercopy can correctly do these checks (right now it's mainly only
useful at checking for overflows in slub and slab), but it'll take
time/focus for a while. No one has had time yet to track all of these
down and fix them. (I defer to Laura and Rik on the design of the
pagespan checks; they did the bulk of the work there.)

Does that help explain it, or am I still missing your question?

-- 
Kees Cook



More information about the Linux-security-module-archive mailing list