public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack3000@gmail.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: "Jann Horn" <jannh@google.com>,
	"Günther Noack" <gnoack@google.com>,
	linux-security-module@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v1 1/2] landlock: Fix log_subdomains_off inheritance across fork()
Date: Tue, 7 Apr 2026 21:00:55 +0200	[thread overview]
Message-ID: <20260407.895b3256373d@gnoack.org> (raw)
In-Reply-To: <20260407.wuaqueid3Pai@digikod.net>

On Tue, Apr 07, 2026 at 06:03:58PM +0200, Mickaël Salaün wrote:
> On Tue, Apr 07, 2026 at 09:30:40AM +0200, Günther Noack wrote:
> > On Sat, Apr 04, 2026 at 10:49:57AM +0200, Mickaël Salaün wrote:
> > > --- a/security/landlock/cred.c
> > > +++ b/security/landlock/cred.c
> > > @@ -22,10 +22,8 @@ static void hook_cred_transfer(struct cred *const new,
> > >  	const struct landlock_cred_security *const old_llcred =
> > >  		landlock_cred(old);
> > >  
> > > -	if (old_llcred->domain) {
> > > -		landlock_get_ruleset(old_llcred->domain);
> > > -		*landlock_cred(new) = *old_llcred;
> > > -	}
> > > +	landlock_get_ruleset(old_llcred->domain);
> > > +	*landlock_cred(new) = *old_llcred;
> > 
> > This fix looks correct for the hook_cred_prepare() case (and of
> > course, hook_cred_prepare() calls hook_cred_transfer() in Landlock).
> > 
> > 
> > But I'm afraid I might have spotted another issue here:
> > 
> > If I look at the code in security/keys/process_keys.c, where
> > security_tranfer_creds() is called, the "old" object is actually
> > already initialized, and if we are not checking for that, I think we
> > are leaking memory.
> 
> old is only a partially initialized credential, and the Landlock
> part is not set yet, which is the goal of hook_transfer_creds(), so
> there is no leak.

Ah, you are right.  I think we might have mixed up the names "old" and
"new" in the discussion briefly, but it's still correct - the target
credential is only partially populated and its Landlock domain is not
set, so we don't need to call landlock_put_ruleset() on it.


> > I would suggest to use the helper landlock_cred_copy() from cred.h for
> 
> This is not required but if we would like to do it anyway, that would
> not be backportable and would introduce a (minimal) performance penalty.

Fair enough, the backportability is a reasonable argument.


> > Test looks fine.
> > 
> > While I do still think we should investigate the memory leak, this
> > commit is, as it is, already a strict improvement over what we had
> > before, so:
> > 
> > Reviewed-by: Günther Noack <gnoack3000@gmail.com>
> 
> I'll keep your tag if this patch is ok with you as-is.

Yes, absolutely.

–Günther

      reply	other threads:[~2026-04-07 19:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-04  8:49 [PATCH v1 1/2] landlock: Fix log_subdomains_off inheritance across fork() Mickaël Salaün
2026-04-04  8:49 ` [PATCH v1 2/2] landlock: Allow TSYNC with LOG_SUBDOMAINS_OFF and fd=-1 Mickaël Salaün
2026-04-07  8:25   ` Günther Noack
2026-04-07 16:06     ` Mickaël Salaün
2026-04-07  7:30 ` [PATCH v1 1/2] landlock: Fix log_subdomains_off inheritance across fork() Günther Noack
2026-04-07 16:03   ` Mickaël Salaün
2026-04-07 19:00     ` Günther Noack [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260407.895b3256373d@gnoack.org \
    --to=gnoack3000@gmail.com \
    --cc=gnoack@google.com \
    --cc=jannh@google.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox