Kernel Panic

Jason A. Donenfeld Jason at
Wed Dec 7 11:38:02 CET 2016

Hey Spender, Pipacs,

On Wed, Dec 7, 2016 at 1:44 AM, PaX Team <pageexec at> wrote:
> that's is your problem, DMA is forbidden to/from the stack in linux,
> Documentation/DMA-API-HOWTO.txt says this:

I realize that you shouldn't shove stack addresses inside
scattergather lists and do DMA with them. I certainly don't do this.
I've read the various parts of the kernel that erroneously do, and
I've looked at the million little grsec patches that replace these
with kmalloc everywhere. That's not what's going on here, however.

In this case, I'm hitting the bug with scatterwalk_map_and_copy, a
function designed to copy bytes out of a DMA region to put them into
any address, even a stack one, for CPU manipulation. The
implementation maps the DMA region, and then essentially calls memcpy
between that region and my stack buffer. This kind of usage certainly
must be permitted.

The place where kstackoverflow gets involved in
scatterwalk_map_and_copy is a small optimization in which the function
exits early if the destination regioin is the same as the source
region. It compares these values by calling virt_to_page and checking
those, and then calling offset_in_page and checking those. But this
doesn't mean anybody is DMAing with the stack.

Grepping the whole tree for other uses of scatterwalk_map_and_copy
indicate that it is widely used as a means of copying stack data to
and from DMA regions with this safe memcpy. For example,

        /* copy authtag to end of dst */
       scatterwalk_map_and_copy(mac, dst, req->cryptlen,
crypto_aead_authsize(aead), 1);

        /* compare calculated auth tag with the stored one */
        scatterwalk_map_and_copy(buf, src, req->cryptlen - authsize,
authsize, 0);
        if (crypto_memneq(mac, buf, authsize))

Not only is `mac` a stack buffer, but it's being used for the same
functional purpose as me -- copying the authtag to/from the stack for
checking or adding.

Looking at the grsec sources for these uses of
scatterwalk_map_and_copy, it doesn't appear that the usual kmalloc
fixup is being applied, which likely indicates you didn't think it was
a problem either.

So -- I think this might be a grsec bug. Or am I still mistaken?


More information about the WireGuard mailing list