linux-kernel - Re: [PATCH] debugfs: Check return value of debugfs_real

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: <20180328061616.GA8212@kroah.com>
Date:   Wed, 28 Mar 2018 08:16:16 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     linux-kernel@...r.kernel.org, Josh Poimboeuf <jpoimboe@...hat.com>,
        Manoj Gupta <manojgupta@...omium.org>
Subject: Re: [PATCH] debugfs: Check return value of debugfs_real_fops() for
 NULL

On Tue, Mar 27, 2018 at 04:55:53PM -0700, Matthias Kaehlcke wrote:
> debugfs_real_fops() returns a NULL pointer when it is invoked without a
> prior call to debugfs_file_get(). In code paths including this call it
> is not strictly necessary to check the return value of
> debugfs_real_fops(). However clang inlines debugfs_real_fops(), detects
> the invalid dereferencing of the NULL pointer and drops the code path.

Wait, what?  Why would it do that, because it thinks dereferencing NULL
is undefined behaviour and it can just do whatever it wants to?

That feels crazy, as for these calls we "know" it will never be NULL
because the previous call to debugfs_file_get() will always ensure it
will be correct.

So this is a case of the compiler trying to be smarter than it really
is, and getting things totally wrong :(

Has anyone reported this to the clang developers?

Papering over compiler foolishness is not something I like to do in
kernel code if at all possible...

thanks,

greg k-h