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  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:	Sat, 30 May 2009 19:21:58 -0700
From:	"Larry H." <>
To:	Linus Torvalds <>
Cc:, Alan Cox <>,
	Rik van Riel <>,
Subject: Re: [PATCH] Change ZERO_SIZE_PTR to point at unmapped space

On 19:02 Sat 30 May     , Linus Torvalds wrote:
> On Sat, 30 May 2009, Larry H. wrote:
> > 
> > Like I said in the reply to Peter, this is 3 extra bytes for amd64 with
> > gcc 4.3.3. I can't be bothered to check other architectures at the
> > moment.
> .. and I can't be bothered with applying this. I'm just not convinced.

The changes don't conflict with anything else (including ERR_PTR and
company). When I said bothered, I implied the change was obviously not
going to differ in any significant way for other architectures.

Like I said, small changes like this are done so we don't need to rely
on mmap_min_addr, which is disabled by default (albeit some
distributions enable it, normally set to 65536).

Let me provide you with a realistic scenario:

	1. foo.c network protocol implementation takes a sockopt which
	sets some ACME_OPTLEN value taken from userland.

	2. the length is not validated properly: it can be zero or an
	integer overflow / signedness issue allows it to wrap to zero.

	3. kmalloc(0) ensues, and data is copied to the pointer
	returned. if this is the default ZERO_SIZE_PTR*, a malicious user
	can mmap a page at NULL, and read data leaked from kernel memory
	everytime that setsockopt is issued.
	(*: kmalloc of zero returns ZERO_SIZE_PTR)

If ZERO_SIZE_PTR points to an unmapped top memory address, this will
trigger a distinctive page fault and the user won't be able to abuse
this for elevating privileges or read kernel memory. Variations of the
scenario above have been present in the kernel, some with exploits being
made available publicly. Most recently, a SCTP sockopt issue.

> It's 3 extra bytes just for the constant. It's also another test, and 
> another branch.

What's the total difference, less than 40 bytes? Do the users of this
macro get impacted? No. Who uses the macro? kzfree/kfree/do_kmalloc/etc.
A dozen users, all in SLAB.

The performance impact, if any, is completely negligible. The security
benefits of this utterly simple change well surpass the downsides.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists