Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 16 Apr 2017 16:25:38 -0400
From: Brad Spengler <>
Subject: Silently (or obliviously) partially-fixed CONFIG_STRICT_DEVMEM bypass

Hi all,

I wanted to provide some small notice of upstream kernel developers silently
or obliviously partially fixing a CONFIG_STRICT_DEVMEM bypass which explicitly has
never been possible in grsecurity in the past 15 years.  I say this because the commit
message makes no mention of this partially fixing a CONFIG_STRICT_DEVMEM bypass (and I
suppose a Secure Boot bypass, but what isn't these days?), and similarly makes no
mentions of the modifications it makes to the write side.  CONFIG_STRICT_DEVMEM exists
to prevent userland from directly modifying kernel memory, yet the kernel will happily
make slab allocations in allowed regions below 1MB.  CONFIG_STRICT_DEVMEM explicitly
allowed both reads and writes to these allocations.  As noted, the commit below doesn't
fix the mmap side.

Feel free to look at GRKERNSEC_KMEM code going back to 2002 in our 2.4.20
patch, or when it changed in 2003 for 2.4.21, or this explicit hunk, comment and
all, that's been around ever since CONFIG_STRICT_DEVMEM was added in 2008:

+       /* throw out everything else below 1MB */
+       if (pagenr <= 256)
+               return 0;

<additional comments/details removed: b76e178e7b24f238ba0dd70104336298f493f0142056a1e5f35c27897369adc6>

While I'm here, some more VMAP_STACK fallout (DoS/potential memory corruption,
adding to the dozen or so posted earlier):


Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ