linux-kernel - Re: [PATCH] mm/sl[aou]b: make kfree() aware of error pointers

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, 10 Sep 2014 10:27:12 -0400
From:	Dave Jones <davej@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm/sl[aou]b: make kfree() aware of error pointers

On Wed, Sep 10, 2014 at 09:56:49AM -0400, Theodore Ts'o wrote:

 > The ironic thing is that I asked Dan to add the feature to smatch
 > because I found two such bugs in ext4, and I suspected there would be
 > more.  Sure enough, it found four more such bugs, including two in a
 > recent commit where I had found the first two bugs --- and I had
 > missed the other two even though I was specifically looking for such
 > instances.  Oops.  :-)
 > 
 > Maybe we can add a debugging config option?  I think having static
 > checkers plus some kmalloc failure testing should be sufficient to
 > prevent these sorts of problem from showing up.
 > 
 > It would seem to me that this is the sort of thing that a static
 > checker should find reliably; Coverity has found things that were more
 > complex than what this should require, I think.  I don't know if they
 > would be willing to add something this kernel-specific, though.  (I've
 > added Dave Jones to the thread since he's been working a lot with
 > Coverity; Dave, what do you think?)

It *might* be possible to rig up something using their modelling 
functionality, but I've not managed to make that work to my ends in the past.

I suspect a runtime check would be more fruitful faster than they could
implement kernel specific checkers & roll them out.

	Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/