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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 27 Jun 2017 21:11:28 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Andi Kleen <ak@...ux.intel.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kees Cook <keescook@...omium.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Hellstrom <thellstrom@...are.com>,
        Daniel Micay <danielmicay@...il.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kref: Avoid null pointer dereference after WARN

On Tue, Jun 27, 2017 at 4:49 PM, Andi Kleen <ak@...ux.intel.com> wrote:
> Is there any data how many security holes this would have
> caught? Please no hand waving. A lot of the recent
> security patches seem to have gone in with just a lot of
> hand waving and security theater

I don't practice security theater. What an offensive insinuation.
Maybe you just meant this about other patches, however.

The point was that if there prior was a WARN_ON, this needs to be a
BUG_ON, since if the WARN_ON was put there with any validity,
continuing after it will always be "fatal and potentially
exploitable". Thus, it'd be better to change that to simply "fatal but
not potentially exploitable". Not security theater. Logic fix.

The bigger question, though, is the value of these checks in the first
place. Has anybody written a coccinelle check to look into this
statically? Has it historically been a useful thing for driver
developers to have? Is it good defense in depth or is it overkill? At
the very least, the original authors of kref thought a WARN_ON was
warranted, which means probably a BUG_ON is a sensible fix, until
somebody does the work of investigating these more careful questions.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ