linux-kernel - Re: [Jfs-discussion] [PATCH] jfs: Expand usercopy whitelist for inline inode data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5j+_qOcnJjwXX9mop++Bs7HCA7QMXCs5VXofewZ7XOwddw@mail.gmail.com>
Date:   Fri, 17 Aug 2018 15:23:09 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Christian Kujau <lists@...dbynature.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Bart Massey <bart.massey@...il.com>,
        jfs-discussion@...ts.sourceforge.net,
        David Windsor <dave@...lcore.net>,
        Dave Kleikamp <shaggy@...nel.org>,
        Ben Hutchings <ben@...adent.org.uk>
Subject: Re: [Jfs-discussion] [PATCH] jfs: Expand usercopy whitelist for
 inline inode data

On Thu, Aug 16, 2018 at 11:56 PM, Christian Kujau <lists@...dbynature.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