linux-kernel - Re: [linux-next-20130422] Bug in SLAB?

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: <5180CCC0.8070703@kernel.org>
Date:	Wed, 01 May 2013 11:05:20 +0300
From:	Pekka Enberg <penberg@...nel.org>
To:	Christoph Lameter <cl@...ux.com>
CC:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	glommer@...allels.com, linux-kernel@...r.kernel.org
Subject: Re: [linux-next-20130422] Bug in SLAB?

On 4/30/13 8:27 PM, Christoph Lameter wrote:
>> "kmalloc() returning NULL for these allocations" is needed by "try kmalloc()
>> first, fallback to vmalloc()" allocation. There are kernel modules which expect
>> kmalloc() to return NULL rather than oops when the requested size is larger
>> than KMALLOC_MAX_SIZE bytes. If kmalloc() suddenly starts triggering oops, such
>> modules will break.
>
> This behavior has been in there for years. Why try a kmalloc that
> always fails since the size is too big?

...because want the extra protection for cases where size is controlled 
by userspace. This is consistent with kcalloc() that returns NULL on 
integer overflow.

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