linux-kernel - Re: kfree(0)

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, 15 Aug 2007 10:34:10 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
Cc:	Rene Herman <rene.herman@...il.com>,
	Jason Uhlenkott <jasonuhl@...onuhl.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Tim Bird <tim.bird@...sony.com>,
	linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: kfree(0) - ok?

On Aug 15, 2007, at 10:06:49, Jan Engelhardt wrote:
> On Aug 15 2007 09:58, Kyle Moffett wrote:
>> Irrespective of whatever the standard says, EVERY platform and  
>> compiler anybody makes nowadays has a NULL pointer value with all  
>> bits clear.  Theoretically the standard allows otherwise, but such  
>> a decision would break so much code.  Linux especially, we rely on  
>> the uninitialized data to have all bits clear and we depend on  
>> that producing NULL pointers; if a NULL pointer was not bitwise  
>> exactly 0 then the test "if (some_ptr != NULL)" would fail and we  
>> would start dereferencing garbage.
>
> But if kmalloc returns NULL on failure, then testing for NULL  
> (irrespective of being 0 or 0xDEADBEEF) is ok.  What would actually  
> concern me then is what "if (!some_ptr)" would do. Probably not the  
> right thing.

Well, what I was referring to is:

static struct foo *some_ptr;

/* Assumes that $SOME_LOCK is held */
int initialize_foo_module()
{
	if (!some_ptr) {
		some_ptr = kmalloc(sizeof(*some_ptr));
		if (!some_ptr)
			return -ENOMEM;

		/* ... */
	}

	/* ... */
}

We initialize all of the static data to all-bits-clear zeros during  
kernel init.  Any platform on which the binary representations of  
"(unsigned long)0" and "(void *)0" are different (even in length, due  
to other issues) will not run the Linux kernel as it stands today.

And as to the sizeof(unsigned long) == sizeof(void *) issue, please  
remember that every Linux compiler is either ILP32 (int, long, and  
pointer are 32-bit) or LP64 (int is 32-bit and long/pointer are 64- 
bit).  We sort of fundamentally rely on these properties in code all  
over the place.

So yes the Linux kernel "breaks the standard" in a bunch of places,  
but on the other hand we're not your average software and we don't  
have to worry about building on an LLP64 compiler (Windows 64-bit and  
some UNIXes) or other strangeness.

Cheers,
Kyle Moffett

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