linux-kernel - Re: [PATCH TRIVIAL] mm: Fix build warning in kmem_cache

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:	Tue, 17 Jul 2012 17:46:13 +0300
From:	Pekka Enberg <penberg@...nel.org>
To:	Christoph Lameter <cl@...ux.com>
Cc:	David Rientjes <rientjes@...gle.com>,
	Shuah Khan <shuah.khan@...com>, glommer@...allels.com,
	js1304@...il.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	shuahkhan@...il.com
Subject: Re: [PATCH TRIVIAL] mm: Fix build warning in kmem_cache_create()

On Mon, 16 Jul 2012, David Rientjes wrote:
>> > The kernel cannot check everything and will blow up in unexpected ways if
>> > someone codes something stupid. There are numerous debugging options that
>> > need to be switched on to get better debugging information to investigate
>> > deper. Adding special code to replicate these checks is bad.
>>
>> Disagree, CONFIG_SLAB does not blow up for a NULL name string and just
>> corrupts userspace.

On Tue, Jul 17, 2012 at 5:36 PM, Christoph Lameter <cl@...ux.com> wrote:
> Ohh.. So far we only had science fiction. Now kernel fiction.... If you
> could corrupt userspace using sysfs with a NULL string then you'd first
> need to fix sysfs support.
>
> And if you really want to be totally safe then I guess you need to audit
> the kernel and make sure that every core kernel function that takes a
> string argument does check for it to be NULL just in case.

Well, even SLUB checks for !name in mainline so that's definitely
worth including unconditionally. Furthermore, the size related checks
certainly make sense and I don't see any harm in having them as well.

As for "in_interrupt()", I really don't see the point in keeping that
around. We could push it down to mm/slab.c in "__kmem_cache_create()"
if we wanted to.

                                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/