linux-kernel - Re: [RFC PATCH v3 00/59] struct filename work

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: <20251216052306.GO1712166@ZenIV>
Date: Tue, 16 Dec 2025 05:23:06 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-fsdevel@...r.kernel.org, brauner@...nel.org, jack@...e.cz,
	mjguzik@...il.com, paul@...l-moore.com, axboe@...nel.dk,
	audit@...r.kernel.org, io-uring@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v3 00/59] struct filename work

On Tue, Dec 16, 2025 at 04:32:03PM +1200, Linus Torvalds wrote:
> So I like the whole series, but..
> 
> On Tue, 16 Dec 2025 at 15:56, Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> >   struct filename ->refcnt doesn't need to be atomic
> 
> Does ->refcnt need to exist _at_all_ if audit isn't enabled?
> 
> Are there any other users of it? Maybe I missed some?
> 
> Because I'm wondering if we could just encapsulate the thing entirely
> in some #ifdef CONFIG_AUDIT check.
> 
> Now, I think absolutely everybody does enable audit, so it's not
> because I'd try to save one word of memory and a few tests, it's more
> of a "could we make it very explicit that all that code is purely
> about the audit case"?

Umm...  Not exactly.  I mean, yes, at the moment we never increment the
refcount outside of kernel/auditsc.c, so it'll always be 1 if that thing
is disabled.

But if you mean to store it on caller's stack, that's another kettle of
fish - anything async with io_uring won't be able to do that, even we
ignore the stack footprint issues.  In configs without audit we end up
	1) allocating it and copying the pathname from userland on
request submission; pointer is stashed into request.
	2) picking it in processing thread and doing the operation
there By that point submitted might have not just left the kernel,
but overwritten the pathname contents in userland.
	3) either stashing it back into request or freeing it.

With audit (2) might become "... and have an extra ref stashed in audit
context" with (3) becoming "either stashing it back into request, if no
extra ref has appeared, or making a copy, stashing it back into request
and dropping the reference on the original"

So refcount may be audit-only thing, at least at the moment, but the
need to outlive the syscall where getname() had been called is very much
not audit-only.

And stack footprint is not trivial either, unless you limit embedded
case to something very short - even an extra hundred bytes (or two,
e.g. in case of rename()) is not something I'd be entirely comfortable
grabbing for pathname-related syscalls.