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: <20260211022341.GL3183987@ZenIV>
Date: Wed, 11 Feb 2026 02:23:41 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Jann Horn <jannh@...gle.com>
Cc: Kees Cook <kees@...nel.org>, 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 Wed, Feb 11, 2026 at 03:06:47AM +0100, Jann Horn 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?
> 
> I'm not an expert, but as far as I know, this path is supposed to be
> really fast (because pretty much every syscall that operates on a path
> will hit it), and doesn't care how much memory it allocates (because
> these allocations are normally only alive for the duration of a
> syscall). strnlen_user() would add another pass over the userspace
> buffer, which I think would probably have negative performance impact?

Sigh...  This is the case of path longer than 168 bytes (EMBEDDED_NAME_MAX);
that's not hard to trigger, but not exactly common.  What matters more is
that we really do not want to deal with the "now it appears to be empty"
case here - it makes the logics in the caller more convoluted and it's not
pretty as it is.

And no, it is not going to be presistent - the longest you can stick such
beasts in there is probably with io-uring; names copied in when request is
submitted and stay around until a worker thread gets around to finishing
the request.