linux-kernel - Re: [PATCH] include/linux/slab.h: new KFREE() macro.

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: <88063.16727.qm@web55602.mail.re4.yahoo.com>
Date:	Tue, 9 Jan 2007 11:02:35 -0800 (PST)
From:	Amit Choudhary <amit2030@...oo.com>
To:	Valdis.Kletnieks@...edu
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Hua Zhong <hzhong@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] include/linux/slab.h: new KFREE() macro.

--- Valdis.Kletnieks@...edu wrote:

> On Mon, 08 Jan 2007 01:06:12 PST, Amit Choudhary said:
> > I do not see how a double free can result in _logical_wrong_behaviour_ of the program and the
> > program keeps on running (like an incoming packet being dropped because of double free).
> Double
> > free will _only_and_only_ result in system crash that can be solved by setting 'x' to NULL.
> 
> The problem is that very rarely is there a second free() with no intervening
> use - what actually *happens* usually is:
> 
> 1) You alloc the memory
> 2) You use the memory
> 3) You take a reference on the memory, so you know where it is.
> 4) You free the memory
> 5) You use the memory via the reference you took in (3)
> 6) You free it again - at which point you finally know for sure that
> everything in step 5 was doing a fandango on core....
> 

Correct. And doing kfree(x); x=NULL; is not hiding that. These issues can still be debugged by
using the slab debugging options. One other benefit of doing this is that if someone tries to
access the same memory again using the variable 'x', then he will get an immediate crash. And the
problem can be solved immediately, without using the slab debugging options. I do not yet
understand how doing this hides the bugs, obfuscates the code, etc. because I haven't seen an
example yet, but only blanket statements.

But now I know better, since I haven't heard anything in support of this case, I have concluded
that doing kfree(x); x=NULL; is _not_needed_ in the "linux kernel". I hope that no one does it in
the future. And since people vehemently opposed this, I think its better to add another item on
the kernel janitor's list to remove all the (x=NULL) statements where people are doing "kfree(x);
x=NULL".

-Amit

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
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/