# CVE-2025-40341: futex: Don't leak robust_list pointer on exec race

> A race condition in the Linux kernel allows local attackers to leak sensitive memory addresses from privileged processes during exec transitions.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 9 Dec 2025
- **Updated:** 11 May 2026
- **Also known as:** BELL-CVE-2025-40341, DEBIAN-CVE-2025-40341, GHSA-j584-qjqw-5mpw, ROOT-OS-DEBIAN-11-CVE-2025-40341, ROOT-OS-DEBIAN-12-CVE-2025-40341, ROOT-OS-DEBIAN-13-CVE-2025-40341, ROOT-OS-UBUNTU-2204-CVE-2025-40341, ROOT-OS-UBUNTU-2404-CVE-2025-40341, UBUNTU-CVE-2025-40341

## What is CVE-2025-40341?

CVE-2025-40341 is a vulnerability in Linux, published on 9 Dec 2025. It can only be exploited from the same machine or local network, with no action from the victim.

### Official 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.

## Which versions are affected by CVE-2025-40341?


## How do I fix CVE-2025-40341?

Apply the vendor's patch.

## Is CVE-2025-40341 being exploited?

There is no known exploitation of CVE-2025-40341 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2025-40341 and fix it if it is affected.

What it is: CVE-2025-40341 is a vulnerability in Linux, published on 9 Dec 2025. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2025-40341 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2025-40341/ (Markdown: https://insights.sbomify.com/CVE-2025-40341/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2025-40341
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-40341
- OSV: https://osv.dev/vulnerability/CVE-2025-40341

---
From sbomify Insights: https://insights.sbomify.com/CVE-2025-40341/
Summaries are generated and may contain mistakes; the official description above is the record.