public inbox for linux-kernel-mentees@lists.linux-foundation.org
 help / color / mirror / Atom feed
From: "André Almeida" <andrealmeid@igalia.com>
To: Pranav Tyagi <pranav.tyagi03@gmail.com>
Cc: jann@thejh.net, keescook@chromium.org,
	linux-kernel@vger.kernel.org, dvhart@infradead.org,
	peterz@infradead.org, mingo@redhat.com, tglx@linutronix.de,
	skhan@linuxfoundation.org, dave@stgolabs.net,
	linux-kernel-mentees@lists.linux.dev
Subject: Re: [PATCH v4] futex: don't leak robust_list pointer on exec race
Date: Thu, 4 Sep 2025 16:52:26 -0300	[thread overview]
Message-ID: <e3e00ba8-1516-4632-b987-4c0d1bb303d5@igalia.com> (raw)
In-Reply-To: <20250813074201.6253-1-pranav.tyagi03@gmail.com>

Hi Pranav,

Thanks for your patch! Some feedback bellow.

Em 13/08/2025 04:42, Pranav Tyagi escreveu:
> sys_get_robust_list() and compat_get_robust_list() use
> ptrace_may_access() to check if the calling task is allowed to access
> another task's robust_list pointer. This check is racy against a
> concurrent exec() in the target process.
> 
> During exec(), a task may transition from a non-privileged binary to a
> privileged one (e.g., setuid binary) and its credentials/memory mappings
> may change. If get_robust_list() performs ptrace_may_access() before
> this transition, it may erroneously allow access to sensitive information
> after the target becomes privileged.
> 
> A racy access allows an attacker to exploit a window
> during which ptrace_may_access() passes before a target process
> transitions to a privileged state via exec().
> 
> For example, consider a non-privileged task T that is about to execute a
> setuid-root binary. An attacker task A calls get_robust_list(T) while T
> is still unprivileged. Since ptrace_may_access() checks permissions
> based on current credentials, it succeeds. However, if T begins exec
> immediately afterwards, it becomes privileged and may change its memory
> mappings. Because get_robust_list() proceeds to access T->robust_list
> without synchronizing with exec() it may read user-space pointers from a
> now-privileged process.
> 
> This violates the intended post-exec access restrictions and could
> expose sensitive memory addresses or be used as a primitive in a larger
> exploit chain. Consequently, the race can lead to unauthorized
> disclosure of information across privilege boundaries and poses a
> potential security risk.
> 
> Take a read lock on signal->exec_update_lock prior to invoking
> ptrace_may_access() and accessing the robust_list/compat_robust_list.
> This ensures that the target task's exec state remains stable during the
> check, allowing for consistent and synchronized validation of
> credentials.
> 
> Signed-off-by: Pranav Tyagi <pranav.tyagi03@gmail.com>
> Suggested-by: Jann Horn <jann@thejh.net>
> Link: https://lore.kernel.org/linux-fsdevel/1477863998-3298-5-git-send-email-jann@thejh.net/
> Link: https://github.com/KSPP/linux/issues/119
> ---
> changed in v4:
> - added task_robust_list() function
> changed in v3:
> - replaced RCU with scoped_guard(rcu)
> - corrected error return type cast
> - added IS_ENABLED(CONFIG_COMPAT) for ensuring compatability
> - removed stray newlines and unnecessary line breaks
> changed in v2:
> - improved changelog
> - helper function for common part of compat and native syscalls
> 
>   kernel/futex/syscalls.c | 108 +++++++++++++++++++++-------------------
>   1 file changed, 58 insertions(+), 50 deletions(-)
> 
> diff --git a/kernel/futex/syscalls.c b/kernel/futex/syscalls.c
> index 4b6da9116aa6..0da33abc2f17 100644
> --- a/kernel/futex/syscalls.c
> +++ b/kernel/futex/syscalls.c
> @@ -39,6 +39,58 @@ SYSCALL_DEFINE2(set_robust_list, struct robust_list_head __user *, head,
>   	return 0;
>   }
>   
> +static inline void __user *task_robust_list(struct task_struct *p, bool compat)

Function names inside of kernel/futex/ have the futex_ prefix

> +{
> +#ifdef CONFIG_COMPAT
> +	if (compat)
> +		return p->compat_robust_list;
> +#endif
> +	return p->robust_list;
> +}
> +
> +static void __user *get_robust_list_common(int pid, bool compat)

Same here

> +{
> +	struct task_struct *p;
> +	void __user *head;
> +	unsigned long ret;

down_read_killable() returns a int, but you are storing the return value 
in an unsigned long.

> +
> +	p = current;

Could this be initialized in the declaration?

> +
> +	scoped_guard(rcu) {
> +		if (pid) {
> +			p = find_task_by_vpid(pid);
> +			if (!p)
> +				return (void __user *)ERR_PTR(-ESRCH);
> +		}
> +		get_task_struct(p);
> +	}
> +
> +	/*
> +	 * Hold exec_update_lock to serialize with concurrent exec()
> +	 * so ptrace_may_access() is checked against stable credentials
> +	 */
> +	ret = down_read_killable(&p->signal->exec_update_lock);
> +	if (ret)
> +		goto err_put;
> +
> +	ret = -EPERM;
> +	if (!ptrace_may_access(p, PTRACE_MODE_READ_REALCREDS))
> +		goto err_unlock;
> +
> +	head = task_robust_list(p, compat);
> +
> +	up_read(&p->signal->exec_update_lock);
> +	put_task_struct(p);
> +
> +	return head;
> +
> +err_unlock:
> +	up_read(&p->signal->exec_update_lock);
> +err_put:
> +	put_task_struct(p);
> +	return (void __user *)ERR_PTR(ret);
> +}
> +
>   /**
>    * sys_get_robust_list() - Get the robust-futex list head of a task
>    * @pid:	pid of the process [zero for current task]
> @@ -49,36 +101,14 @@ SYSCALL_DEFINE3(get_robust_list, int, pid,
>   		struct robust_list_head __user * __user *, head_ptr,
>   		size_t __user *, len_ptr)
>   {
> -	struct robust_list_head __user *head;
> -	unsigned long ret;
> -	struct task_struct *p;
> -
> -	rcu_read_lock();
> -
> -	ret = -ESRCH;
> -	if (!pid)
> -		p = current;
> -	else {
> -		p = find_task_by_vpid(pid);
> -		if (!p)
> -			goto err_unlock;
> -	}
> +	struct robust_list_head __user *head = get_robust_list_common(pid, false);
>   
> -	ret = -EPERM;
> -	if (!ptrace_may_access(p, PTRACE_MODE_READ_REALCREDS))
> -		goto err_unlock;
> -
> -	head = p->robust_list;
> -	rcu_read_unlock();
> +	if (IS_ERR(head))
> +		return PTR_ERR(head);
>   
>   	if (put_user(sizeof(*head), len_ptr))
>   		return -EFAULT;
>   	return put_user(head, head_ptr);
> -
> -err_unlock:
> -	rcu_read_unlock();
> -
> -	return ret;
>   }
>   
>   long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout,
> @@ -455,36 +485,14 @@ COMPAT_SYSCALL_DEFINE3(get_robust_list, int, pid,
>   			compat_uptr_t __user *, head_ptr,
>   			compat_size_t __user *, len_ptr)
>   {
> -	struct compat_robust_list_head __user *head;
> -	unsigned long ret;
> -	struct task_struct *p;
> -
> -	rcu_read_lock();
> -
> -	ret = -ESRCH;
> -	if (!pid)
> -		p = current;
> -	else {
> -		p = find_task_by_vpid(pid);
> -		if (!p)
> -			goto err_unlock;
> -	}
> -
> -	ret = -EPERM;
> -	if (!ptrace_may_access(p, PTRACE_MODE_READ_REALCREDS))
> -		goto err_unlock;
> +	struct compat_robust_list_head __user *head = get_robust_list_common(pid, true);
>   
> -	head = p->compat_robust_list;
> -	rcu_read_unlock();
> +	if (IS_ERR(head))
> +		return PTR_ERR(head);
>   
>   	if (put_user(sizeof(*head), len_ptr))
>   		return -EFAULT;
>   	return put_user(ptr_to_compat(head), head_ptr);
> -
> -err_unlock:
> -	rcu_read_unlock();
> -
> -	return ret;
>   }
>   #endif /* CONFIG_COMPAT */
>   


  parent reply	other threads:[~2025-09-04 19:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-13  7:42 [PATCH v4] futex: don't leak robust_list pointer on exec race Pranav Tyagi
2025-08-21 11:47 ` Pranav Tyagi
2025-09-04  7:40 ` Pranav Tyagi
2025-09-04 19:52 ` André Almeida [this message]
2025-09-07 10:26   ` Pranav Tyagi

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=e3e00ba8-1516-4632-b987-4c0d1bb303d5@igalia.com \
    --to=andrealmeid@igalia.com \
    --cc=dave@stgolabs.net \
    --cc=dvhart@infradead.org \
    --cc=jann@thejh.net \
    --cc=keescook@chromium.org \
    --cc=linux-kernel-mentees@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pranav.tyagi03@gmail.com \
    --cc=skhan@linuxfoundation.org \
    --cc=tglx@linutronix.de \
    /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