linux-kernel - Re: [GIT PULL] x86/build changes for v4.17

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]

Date:   Wed, 4 Apr 2018 15:29:18 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     James Y Knight <jyknight@...gle.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Chandler Carruth <chandlerc@...gle.com>,
        Stephen Hines <srhines@...gle.com>,
        Kees Cook <keescook@...gle.com>,
        Guenter Roeck <groeck@...omium.org>,
        Greg Hackmann <ghackmann@...gle.com>
Subject: Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 3:21 PM, James Y Knight <jyknight@...gle.com> wrote:
>
> But allowing random pointer arithmetic, and pointer arithmetic wraparound,
> is still different than asserting that an object _field access_ can
> overflow.

But that's not what the code does.

It never _accessed_ the field. It only looked at the *address* of the field.

So clang got this case wrong:

        &(pos)->member != NULL

where that "&" thing is very much important. There was no access. An
access would in fact have been a bug (and was the bug that the
compiler caused, because it removed the check for NULL).

You may consider this an "access", but to me, it's all just pointer
arithmetic, and not in the least different from the kind of pointer
arithmetic that "offsetof()" traditionally does.

So I think your "it's a field access" is just a syntactic argument and
should not semantically be *any* different from doing arithmetic on a
pointer.

            Linus