[PATCH v6 3/9] landlock: Control pathname UNIX domain socket resolution by path

[Justin Suess]

On Wed, Mar 18, 2026 at 05:26:20PM +0100, Mickaël Salaün wrote:
> On Wed, Mar 18, 2026 at 04:05:59PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2026-03-18 10:14:52 [-0400], Justin Suess wrote:
> > > Sebastian,
> > Justin,
> > 
> > > In short: dom_other is a pointer to a landlock-owned refcounted struct.
> > …
> > > 
> > > But we copy the domain pointer, which points to a landlock allocated
> > > and controlled object.
> > 
> > and this is not going away while we are here and preempted after
> > dropping the lock? (if the landlock policy is updated/ changed/ …)
> 
> I agree with Sebastian, this is a bug, see my original proposal:
> https://lore.kernel.org/all/20260217.lievaS8eeng8@digikod.net/
Mickaël,

Just to make sure we're speaking of the same thing (I spotted a bug
shortly after replying to Sebastian).

This is a potential UAF if the dom_other is freed before the access
check takes place correct?

	dom_other = landlock_cred(other->sk_socket->file->f_cred)->domain;
	unix_state_unlock(other);

	unmask_scoped_access(subject->domain, dom_other, &layer_masks,
			     fs_resolve_unix.fs);

If the dom_other->usage reaches zero, then the domain could be
freed after the unix_state_unlock while we're checking access??

(I guess I assumed the sock_hold on the @other would prevent the task
@other belongs to from being freed.)

Would it be better to move the access check under the unix_state_lock or
to acquire another reference to the ruleset (or something else)?

(Good catch Sebastian sorry for the confusion.)

Justin