On Thu, Aug 16, 2018 at 11:56 PM, Christian Kujau <li...@nerdbynature.de> wrote: > On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote: >> Bart Massey reported what turned out to be a usercopy whitelist false >> positive in JFS when symlink contents exceeded 128 bytes. The inline >> inode data (i_inline) is actually designed to overflow into the "extended > > So, this may be a stupid question, but: is there a way to disable this > hardened usercopy thing with a boot option maybe? > > Apparently, CONFIG_HARDENED_USERCOPY_FALLBACK was disabled in Debian's > 4.16.0-0.bpo.2-amd64 (4.16.16) kernels[0] and I have a VMware guest here > that prints a BUG message (below) whenever a certain directory is being > accesses. ls(1) is fine, but "ls -l" (i.e. with stat()) produces the splat > below. And indeed, the target of one of the symlinks inside is 129 > characters long, and every attempt to stat it prints the splat below. > > Going back to 4.16.0-0.bpo.1-amd64 (4.16.5) helps, but I was wondering if > there was a magic boot option to disable it while I wait for 4.18 to land > in Debian? I booted with hardened_usercopy=off, but it doesn't seem to > have an effect and the directory is still inaccessible.
Precisely this was just added upstream[1] for 4.19 but isn't available in 4.16. It should be trivial to backport it, though, if Ben wants to do that? (The JFS fix is in the 4.17 and 4.18 -stable trees now, too, BTW.) -Kees [1] https://git.kernel.org/linus/b5cb15d9372a -- Kees Cook Pixel Security