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: <200701082243.l08Mh8UR007559@turing-police.cc.vt.edu>
Date:	Mon, 08 Jan 2007 17:43:08 -0500
From:	Valdis.Kletnieks@...edu
To:	Amit Choudhary <amit2030@...oo.com>
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.

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....

Content of type "application/pgp-signature" skipped