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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <590a36e6-8d11-411a-8fcd-d93eef96f0e9@redhat.com>
Date: Tue, 3 Feb 2026 15:32:04 -0500
From: Waiman Long <llong@...hat.com>
To: Al Viro <viro@...iv.linux.org.uk>
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 2/3/26 3:05 PM, Al Viro wrote:
> On Tue, Feb 03, 2026 at 02:44:33PM -0500, Waiman Long wrote:
>
>> diff --git a/kernel/audit.h b/kernel/audit.h
>> index 7c401729e21b..03f3539b10e7 100644
>> --- a/kernel/audit.h
>> +++ b/kernel/audit.h
>> @@ -133,6 +133,13 @@ struct audit_context {
>>   	int		    name_count; /* total records in names_list */
>>   	struct list_head    names_list;	/* struct audit_names->list anchor */
>>   	char		    *filterkey;	/* key for rule that triggered record */
>> +	/*
>> +	 * pwd_reset is set if audit_free_names() has been called from
>> +	 * audit_reset_context() to reset pwd, but pwd is still holding dentry
>> +	 * and mount references to be used in later audit action without
>> +	 * the need to reacqure the references again.
> That's a delicate way to say "we have mounts stuck busy inexplicably for userland"...
>
> Generally a chdir(2) away from something immediately followed by umount(2)
> is _not_ expected to leave you with -EBUSY when nobody else has been doing
> anything with the mount in question.

That is actually a concern that I have at the back of my mind. I can 
modify the patch to cache only the dentry and do get/put the mount every 
time which is much cheaper as it is a percpu counter.  In that way, a 
chdir(2) followed by a umount(2) shouldn't cause a -EBUSY. Right?

Cheers,
Longman