linux-kernel - Re: [PATCH] futex: don't leak robust

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] [day] [month] [year] [list]

Message-ID: <87frg3ss9s.ffs@tglx>
Date: Fri, 13 Jun 2025 15:08:47 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Pranav Tyagi <pranav.tyagi03@...il.com>
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
 Darren Hart <dvhart@...radead.org>, Davidlohr Bueso <dave@...olabs.net>,
 André Almeida <andrealmeid@...lia.com>,
 linux-kernel@...r.kernel.org,
 jann@...jh.net, keescook@...omium.org, skhan@...uxfoundation.org,
 linux-kernel-mentees@...ts.linux.dev
Subject: Re: [PATCH] futex: don't leak robust_list pointer on exec race

On Wed, Jun 11 2025 at 19:33, Pranav Tyagi wrote:
> On Mon, Jun 9, 2025 at 3:15 PM Thomas Gleixner <tglx@...utronix.de> wrote:
> Does the revised version below address the concerns more effectively
> or does it still need a bit more seasoning?
>
> "Currently, sys_get_robust_list() and compat_get_robust_list() perform a
> ptrace_may_access() check to verify if the calling task is allowed to
> query another task’s robust_list pointer. However, this check is racy
> against a concurrent exec() in the target process.
>
> During exec(), a task's credentials and memory mappings can change, and
> the task may transition from a non-privileged binary to a privileged one
> (e.g., a setuid binary). If get_robust_list() performs ptrace_may_access()
> before this transition, it may wrongly allow access to sensitive
> information after the target becomes privileged.
>
> To address this, a read lock is taken on signal->exec_update_lock prior
> to invoking ptrace_may_access() and accessing the robust_list. This
> ensures that the target task's exec state remains stable during the
> check, allowing for consistent and synchronized validation of
> credentials."

That's way better, but it still does not explain what the consequences
of the racy access are.
>>
>> You really did not have a better idea than copying all of that logic
>> into the compat code?
>
> As I’m still learning, I wasn’t quite sure how to avoid
> duplication there. Would factoring out the common logic into a helper function
> be the right direction? I’d be grateful for your suggestion.

Exactly.

Thanks,

        tglx