All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Kees Cook <kees@kernel.org>
Cc: Paul Moore <paul@paul-moore.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] yama: don't abuse rcu_read_lock/get_task_struct in yama_task_prctl()
Date: Wed, 19 Feb 2025 21:17:42 +0100	[thread overview]
Message-ID: <20250219201742.GD5948@redhat.com> (raw)
In-Reply-To: <202502191125.1A6F07E@keescook>

On 02/19, Kees Cook wrote:
>
> On Wed, Feb 19, 2025 at 05:14:17PM +0100, Oleg Nesterov wrote:
> > current->group_leader is stable, no need to take rcu_read_lock() and do
> > get/put_task_struct().
>
> Can you explain why this is true? In trying to figure this out again,
> it seems that the only way current->group_leader can vanish is if
> the entire process vanishes (fork or thread exec), in which case the
> "current" in this prctl can't be happening; this appears to be locked
> behind tsk->sighand->siglock ?

Well, almost, but this has nothing to do with tsk->sighand->siglock...

task->group_leader can only be changed by thread exec, when a non leader
thread does exec, see de_thread(). But de_thread() can't succeed and change
->group_leader until all other threads exit, see the "Kill all other threads
in the thread group" code in de_thread(). The "current" task can't exit, so
current->group_leader is stable.

Note also that we already have a lot of current->group_leader users which
don't use rcu/get_task_struct.

That said, we have a lot of buggy users of tsk->group_leader when
same_thread_group(tsk, current) != true ;) For example, sys_prlimit64().
And note that rcu_read_lock/get_task_struct can't help in this case.
I am going to send some fixes.

Oleg.

> 
> -Kees
> 
> > 
> > Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> > ---
> >  security/yama/yama_lsm.c | 9 ++-------
> >  1 file changed, 2 insertions(+), 7 deletions(-)
> > 
> > diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
> > index 1971710620c1..3d064dd4e03f 100644
> > --- a/security/yama/yama_lsm.c
> > +++ b/security/yama/yama_lsm.c
> > @@ -222,7 +222,7 @@ static int yama_task_prctl(int option, unsigned long arg2, unsigned long arg3,
> >  			   unsigned long arg4, unsigned long arg5)
> >  {
> >  	int rc = -ENOSYS;
> > -	struct task_struct *myself = current;
> > +	struct task_struct *myself;
> >  
> >  	switch (option) {
> >  	case PR_SET_PTRACER:
> > @@ -232,11 +232,7 @@ static int yama_task_prctl(int option, unsigned long arg2, unsigned long arg3,
> >  		 * leader checking is handled later when walking the ancestry
> >  		 * at the time of PTRACE_ATTACH check.
> >  		 */
> > -		rcu_read_lock();
> > -		if (!thread_group_leader(myself))
> > -			myself = rcu_dereference(myself->group_leader);
> > -		get_task_struct(myself);
> > -		rcu_read_unlock();
> > +		myself = current->group_leader;
> >  
> >  		if (arg2 == 0) {
> >  			yama_ptracer_del(NULL, myself);
> > @@ -255,7 +251,6 @@ static int yama_task_prctl(int option, unsigned long arg2, unsigned long arg3,
> >  			}
> >  		}
> >  
> > -		put_task_struct(myself);
> >  		break;
> >  	}
> >  
> > -- 
> > 2.25.1.362.g51ebf55
> > 
> > 
> 
> -- 
> Kees Cook
> 


  reply	other threads:[~2025-02-19 20:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19 16:14 [PATCH] yama: don't abuse rcu_read_lock/get_task_struct in yama_task_prctl() Oleg Nesterov
2025-02-19 19:33 ` Kees Cook
2025-02-19 20:17   ` Oleg Nesterov [this message]
2025-02-19 21:00     ` Oleg Nesterov
2025-02-19 21:42       ` Oleg Nesterov
2025-03-04 23:53 ` Kees Cook

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=20250219201742.GD5948@redhat.com \
    --to=oleg@redhat.com \
    --cc=jmorris@namei.org \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.