linux-cve-announce - CVE-2025-40341: 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>] [day] [month] [year] [list]

Message-ID: <2025120912-CVE-2025-40341-c778@gregkh>
Date: Tue,  9 Dec 2025 13:10:23 +0900
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-40341: futex: Don't leak robust_list pointer on exec race

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

futex: Don't leak robust_list pointer on exec race

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.

The Linux kernel CVE team has assigned CVE-2025-40341 to this issue.

Affected and fixed versions
===========================

	Fixed in 6.1.159 with commit 6511984d1aa1360181bcafb1ca75df7f291ef237
	Fixed in 6.6.117 with commit 4aced32596ead1820b7dbd8e40d30b30dc1f3ad4
	Fixed in 6.12.58 with commit 3b4222494489f6d4b8705a496dab03384b7ca998
	Fixed in 6.17.8 with commit b524455a51feb6013df3a5dba3160487b2e8e22a
	Fixed in 6.18 with commit 6b54082c3ed4dc9821cdf0edb17302355cc5bb45

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-40341
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	kernel/futex/syscalls.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/6511984d1aa1360181bcafb1ca75df7f291ef237
	https://git.kernel.org/stable/c/4aced32596ead1820b7dbd8e40d30b30dc1f3ad4
	https://git.kernel.org/stable/c/3b4222494489f6d4b8705a496dab03384b7ca998
	https://git.kernel.org/stable/c/b524455a51feb6013df3a5dba3160487b2e8e22a
	https://git.kernel.org/stable/c/6b54082c3ed4dc9821cdf0edb17302355cc5bb45