linux-kernel - Re: [PATCH v2] audit: Avoid excessive dput/dget in audit

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] [day] [month] [year] [list]

Message-ID: <20260204201815.GP3183987@ZenIV>
Date: Wed, 4 Feb 2026 20:18:15 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Waiman Long <llong@...hat.com>
Cc: Paul Moore <paul@...l-moore.com>, Eric Paris <eparis@...hat.com>,
	Christian Brauner <brauner@...nel.org>,
	linux-kernel@...r.kernel.org, audit@...r.kernel.org,
	Richard Guy Briggs <rgb@...hat.com>,
	Ricardo Robaina <rrobaina@...hat.com>
Subject: Re: [PATCH v2] audit: Avoid excessive dput/dget in audit_context
 setup and reset paths

On Wed, Feb 04, 2026 at 01:16:15PM -0500, Waiman Long wrote:

> Thanks for the detailed explanation. I am thinking about something like
> the code diff below. Of course, there are other corner cases like unshare(2)
> that still needs to be handled. Do you think something like this is viable?

Deadlocks aside, the immediate problem here is that consensus number is too
low.  Take three threads sharing the same fs_struct instance.  The first one
calls your get_fs_pwd_share(); then the remaining two threads call set_fs_pwd()
(e.g. by calling chdir(2) in userland code).  The reference stored into
fs->pwd_waiter by the first of those two gets overwritten by that stored
by the second.  When the caller of get_fs_pwd_share() gets to put_fs_pwd_share(),
only one of the sleepers gets woken up...

And it's very easy to end up with something as simple as chdir("foo") deadlocking -
we start with resolving the relative pathname we'd been given, audit wants to
record the current directory, on the theory that relative pathname is none too
useful in logs without knowing what had it been relative to.  Then, in the
same thread, you call set_fs_pwd() - after all, that's the main effect of chdir(2).
Deadlock...

IOW, it's not just unshare(2) that needs to be taken care of - chdir(2) would need
to be treated differently.