linux-hardening - Re: [PATCH] fs: Keep long filenames in isolated slab buckets

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: <20260211021539.GK3183987@ZenIV>
Date: Wed, 11 Feb 2026 02:15:39 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Kees Cook <kees@...nel.org>
Cc: Jann Horn <jannh@...gle.com>, Christian Brauner <brauner@...nel.org>,
	Jan Kara <jack@...e.cz>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] fs: Keep long filenames in isolated slab buckets

On Tue, Feb 10, 2026 at 05:41:43PM -0800, Kees Cook wrote:

> > I think this path, where we always do maximally-sized allocations, is
> > the normal case where we're handling paths coming from userspace...
> 
> Actually, is there any reason we can't use strnlen_user() in
> do_getname(), and then just use strndup_user() in the long case?

Yes.  Not having to deal with the "oh, lookie - it became empty this
time around" case.


> > >         if (len <= EMBEDDED_NAME_MAX) {
> > >                 p = (char *)result->iname;
> > > -               memcpy(p, filename, len);
> > >         } else {
> > > -               p = kmemdup(filename, len, GFP_KERNEL);
> > > +               p = kmem_buckets_alloc(names_buckets, len, GFP_KERNEL);
> > 
> > ... while this is kind of the exceptional case, where paths are coming
> > from kernelspace.

mount -t ext2 fucking_long_pathname_resolving_to_dev_sda1 /mnt

Watch the show.  "Fucking long" here being "longer than 150 bytes or so".