Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: pageexec@freemail.hu
Cc: Brad Spengler <spender@grsecurity.net>,
	WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Kernel Panic
Date: Wed, 7 Dec 2016 11:38:02 +0100	[thread overview]
Message-ID: <CAHmME9rHB20Ywi_ZkFGq5WioqeDApUvaTwaOP1HB1WBpYRVCag@mail.gmail.com> (raw)
In-Reply-To: <58475B7C.14182.19D586@pageexec.freemail.hu>

Hey Spender, Pipacs,

On Wed, Dec 7, 2016 at 1:44 AM, PaX Team <pageexec@freemail.hu> 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,
arch/arm64/crypto/aes-ce-ccm-glue.c:

        /* 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?

Jason

  reply	other threads:[~2016-12-07 10:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-06  6:23 Samuel Holland
2016-12-06 18:19 ` Jason A. Donenfeld
2016-12-06 18:26   ` Samuel Holland
2016-12-06 18:31     ` Jason A. Donenfeld
2016-12-06 22:39       ` Jason A. Donenfeld
2016-12-07  0:44         ` PaX Team
2016-12-07 10:38           ` Jason A. Donenfeld [this message]
     [not found]             ` <CAHmME9pVCDu88c6n+LV9Mtd5Ohu8o-7RSQB4kRjsHGRQ3jF8zw@mail.gmail.com>
     [not found]               ` <20161208231626.GA5230@grsecurity.net>
2016-12-09 11:17                 ` Jason A. Donenfeld
     [not found]                   ` <20161209121144.GA31448@grsecurity.net>
2016-12-09 12:56                     ` Jason A. Donenfeld
2016-12-09 13:27                       ` Jason A. Donenfeld
2016-12-09 15:54 ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHmME9rHB20Ywi_ZkFGq5WioqeDApUvaTwaOP1HB1WBpYRVCag@mail.gmail.com \
    --to=jason@zx2c4.com \
    --cc=pageexec@freemail.hu \
    --cc=spender@grsecurity.net \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).