linux-kernel - Re: [PATCH v2 24/33] user: support ns lookup

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: <aqu3yraxpt7h7rxjzzwvelcwvn7ehzufydhye57w6c6n2spddp@5pdsdhgfbxy5>
Date: Mon, 15 Sep 2025 16:14:50 +0200
From: Jan Kara <jack@...e.cz>
To: Christian Brauner <brauner@...nel.org>
Cc: Jan Kara <jack@...e.cz>, Amir Goldstein <amir73il@...il.com>, 
	linux-fsdevel@...r.kernel.org, Josef Bacik <josef@...icpanda.com>, 
	Jeff Layton <jlayton@...nel.org>, Mike Yuan <me@...dnzj.com>, 
	Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>, Lennart Poettering <mzxreary@...inter.de>, 
	Daan De Meyer <daan.j.demeyer@...il.com>, Aleksa Sarai <cyphar@...har.com>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Jens Axboe <axboe@...nel.dk>, Tejun Heo <tj@...nel.org>, 
	Johannes Weiner <hannes@...xchg.org>, Michal Koutný <mkoutny@...e.com>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	Chuck Lever <chuck.lever@...cle.com>, linux-nfs@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org, cgroups@...r.kernel.org, 
	netdev@...r.kernel.org
Subject: Re: [PATCH v2 24/33] user: support ns lookup

On Mon 15-09-25 15:54:26, Christian Brauner wrote:
> On Mon, Sep 15, 2025 at 02:11:55PM +0200, Jan Kara wrote:
> > On Fri 12-09-25 13:52:47, Christian Brauner wrote:
> > > Support the generic ns lookup infrastructure to support file handles for
> > > namespaces.
> > > 
> > > Signed-off-by: Christian Brauner <brauner@...nel.org>
> > ...
> > > @@ -200,6 +202,7 @@ static void free_user_ns(struct work_struct *work)
> > >  	do {
> > >  		struct ucounts *ucounts = ns->ucounts;
> > >  		parent = ns->parent;
> > > +		ns_tree_remove(ns);
> > >  		if (ns->gid_map.nr_extents > UID_GID_MAP_MAX_BASE_EXTENTS) {
> > >  			kfree(ns->gid_map.forward);
> > >  			kfree(ns->gid_map.reverse);
> > > @@ -218,7 +221,8 @@ static void free_user_ns(struct work_struct *work)
> > >  		retire_userns_sysctls(ns);
> > >  		key_free_user_ns(ns);
> > >  		ns_free_inum(&ns->ns);
> > > -		kmem_cache_free(user_ns_cachep, ns);
> > > +		/* Concurrent nstree traversal depends on a grace period. */
> > > +		kfree_rcu(ns, ns.ns_rcu);
> > 
> > So this is correct for now but it's a bit of a landmine. A lot of stuff
> > that ns references is kfreed before the RCU expires. Thus if you lookup ns
> > using id, then even if you're under RCU protection you have to be very
> > careful about what you can and cannot dereference. IMHO this deserves a
> > careful documentation at least or, preferably, split free_user_ns() into
> > pre and post-RCU period parts...
> 
> Right, the thing is that you cannot touch anything in any namespace
> structure without having an actual reference to it. IOW, the only thing
> that's valid under rcu is to access the reference count. That's the only
> guarantee that the _generic_ infrastructure gives _and_ expects. IOW, if
> one can get a live reference (inc_not_zero) that thing better be valid.
> 
> Individual namespace implementers may ofc provide additional guarantees
> but they are not transparent to the generic infrastructure.
> 
> Otherwise I fully agree.

I guess fair enough for this patch set so feel free to add:

Reviewed-by: Jan Kara <jack@...e.cz>

but longer term we might need to revisit this.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR