Linux kernel
cpe:2.3:a:linux:linux_kernel:*:*:*:*:*:*:*, +4 more
A vulnerability in the Linux kernel's handling of robust lists can lead to unauthorized information disclosure across privilege boundaries. This issue arises in the futex subsystem, specifically within the 'sys_get_robust_list()' and 'compat_get_robust_list()' system calls. These calls use 'ptrace_may_access()' to determine if the calling task can access another task's robust list pointer. However, this check is susceptible to a race condition with concurrent 'exec()' calls in the target process. During execution, a task may shift from a non-privileged to a privileged state (such as when executing a setuid binary), potentially altering its memory mappings and credentials. If 'get_robust_list()' performs the access check before this transition, it could mistakenly permit access to sensitive information after the task gains privileges. Exploiting this race allows reading user-space pointers from a now-privileged process, violating post-exec access restrictions and possibly exposing critical memory addresses or serving as a building block for more extensive exploits.
The vulnerability can lead to unauthorized disclosure of information across privilege boundaries, with the potential to expose sensitive memory addresses that could be exploited in a larger attack chain.
To reproduce this vulnerability, a non-privileged task must be made to execute a setuid-root binary. While the task is still unprivileged, an attacker can call 'get_robust_list()' on it. If this is done before the task transitions to a privileged state, the 'ptrace_may_access()' check will incorrectly allow access to the robust list pointer. Once the task executes and gains privileges, the attacker can exploit the race to read sensitive information from the task's memory.
The vulnerability has been addressed by modifying the 'get_robust_list()' and 'compat_get_robust_list()' functions to include a read lock on the task's execution state. This change ensures that the 'ptrace_may_access()' check is performed against stable credentials, preventing the race condition with 'exec()'.
Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.