Kernel Panic

[Jason A. Donenfeld]

On Fri, Dec 9, 2016 at 1:11 PM, Brad Spengler <spender at grsecurity.net> wrote:
> It's not potentially, it is trouble.  That code didn't use to be there
> btw, that optimization was introduced sometime between 3.14 and 4.4.
> So you could take your pick I guess, either that code is wrong or yours
> is wrong ;)  As a third-party module generally that makes your code
> "wrong" (because it being fixed in 4.9 won't help all the other versions
> out there that exist) but I do indeed pass through the original buffer
> through the rest of the function, as it's only the virt_to_page that's
> the problem.

It was added with v4.0-6954-g74412fd5d71b, so I guess this means it
arrived at 4.1.

Quite clearly the kernel code is "wrong", since the vast majority of
other callers in the kernel also use it with the quite reasonable
assumption that simple memcpy is stack-safe. When all of the consumers
assume a function will work in a particular way, and then upstream
tries to "optimize" the function and breaks things, that usually means
it's a problem with the optimization, not with the consumers.

Anyway, what I suspect the upstream response will be is that since
this is just a check of equality of addresses, with no dereferencing,
it will always (?) just be false for stack addresses, and so there's
no functional detriment, despite it being not correct. Or some boring
reasoning along these lines.

But anyway, splitting hairs... I'll monitor the grsec changelog and
ping the guy on the wireguard mailing list who ran into the issue when
it's fixed.