linux-kernel - Re: [RFC 2/1] kill task_ucounts()->rcu_read_lock(), add __task

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: <bf07a721-ed57-4b8f-af4f-ca2dd21b12b0@paulmck-laptop>
Date: Mon, 27 Oct 2025 08:18:52 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: Oleg Nesterov <oleg@...hat.com>, Alexey Gladkov <legion@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mateusz Guzik <mjguzik@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC 2/1] kill task_ucounts()->rcu_read_lock(), add
 __task_ucounts()

On Mon, Oct 27, 2025 at 02:55:56PM +0000, David Howells wrote:
> Oleg Nesterov <oleg@...hat.com> wrote:
> 
> > So I think task_ucounts() can just do
> > 
> > 	/* The caller must ensure that ->real_cred is stable or take rcu_read_lock() */
> > 	#define task_ucounts(task)	\
> > 		rcu_dereference_check((task)->real_cred, 1)->ucounts
> 
> Can you use rcu_access_pointer() within exit.c?  E.g.:
> 
> 	struct cred *pcreds = rcu_access_pointer(task->real_cred);
> 	dec_rlimit_ucounts(pcreds->ucounts, UCOUNT_RLIMIT_NPROC, 1);

No go, unfortunately.  You can only use rcu_access_pointer() if you are
*not* dereferencing it.  And here, dereferencing is happening.

However, if there is some mutex that is preventing changes to ->real_cred,
then something like this would work:

	struct cred *pcreds = rcu_dereference_protected(task->real_cred mutex_is_locked(&whatever));

Alternatively, if this is due to the running kthread being in some
state, then a check for that state can be substituted for the above
mutex_is_locked().  And so on.

							Thanx, Paul