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: <alpine.LNX.2.00.1409100702190.5523@pobox.suse.cz>
Date:	Wed, 10 Sep 2014 07:05:40 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	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,
	Dan Carpenter <dan.carpenter@...cle.com>,
	Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH] mm/sl[aou]b: make kfree() aware of error pointers

On Tue, 9 Sep 2014, Andrew Morton wrote:

> > kfree() is happy to accept NULL pointer and does nothing in such case. 
> > It's reasonable to expect it to behave the same if ERR_PTR is passed to 
> > it.
> > 
> > Inspired by a9cfcd63e8d ("ext4: avoid trying to kfree an ERR_PTR 
> > pointer").
> > 
> > ...
> >
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -3612,7 +3612,7 @@ void kfree(const void *objp)
> >  
> >  	trace_kfree(_RET_IP_, objp);
> >  
> > -	if (unlikely(ZERO_OR_NULL_PTR(objp)))
> > +	if (unlikely(ZERO_OR_NULL_PTR(objp) || IS_ERR(objp)))
> >  		return;
> 
> kfree() is quite a hot path to which this will add overhead.  And we
> have (as far as we know) no code which will actually use this at
> present.

We obviously don't, as such code will be causing explosions. This is meant 
as a prevention of problems such as the one that has just been fixed in 
ext4.

> How about a new
> 
> kfree_safe(...)
> {
> 	if (IS_ERR(...))
> 		return;
> 	if (other-stuff-when-we-think-of-it)
> 		return;
> 	kfree(...);
> }

I think this unfortunately undermines the whole point of the patch ... if 
the caller knows that he might potentially be feeding ERR_PTR() to 
kfree(), he can as well check the pointer himself.

-- 
Jiri Kosina
SUSE Labs
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ