CVE-2025-40341

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

futex: Don't leak robust_list pointer on exec race

sysgetrobustlist() and compatgetrobustlist() use ptracemayaccess() 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 getrobustlist() performs ptracemayaccess() 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 ptracemayaccess() 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 getrobustlist(T) while T is still unprivileged. Since ptracemayaccess() 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 getrobustlist() 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->execupdatelock prior to invoking ptracemayaccess() and accessing the robustlist/compatrobust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials.