Skip to main content

Linux Kernel CVE-2025-39976

HIGH
2025-10-15 416baaa9-dc9f-4396-8d5f-8c081fb06d67
7.8
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
5.8 MEDIUM

Local low-priv attacker (AV:L/PR:L); AC:H because it requires forcing a non-deterministic allocation failure during fork; primary realistic impact is kernel panic (A:H) with limited, uncertain C/I effect.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N
SUSE
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat
4.5 MEDIUM
qualitative

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Analysis Generated
Jul 30, 2026 - 08:08 vuln.today
CVE Published
Oct 15, 2025 - 08:15 cve.org
HIGH 7.8

DescriptionCVE.org

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

futex: Use correct exit on failure from futex_hash_allocate_default()

copy_process() uses the wrong error exit path from futex_hash_allocate_default(). After exiting from futex_hash_allocate_default(), neither tasklist_lock nor siglock has been acquired. The exit label bad_fork_core_free unlocks both of these locks which is wrong.

The next exit label, bad_fork_cancel_cgroup, is the correct exit. sched_cgroup_fork() did not allocate any resources that need to freed.

Use bad_fork_cancel_cgroup on error exit from futex_hash_allocate_default().

AnalysisAI

Local privilege escalation and memory corruption in the Linux kernel process-creation path arises because copy_process() takes the wrong error-exit label after futex_hash_allocate_default() fails, releasing tasklist_lock and siglock that were never acquired. This lock imbalance can corrupt kernel synchronization state on the fork error path, with a potential for kernel crash or exploitation to gain elevated privileges. No public exploit identified at time of analysis and EPSS is low (0.17%), consistent with a subtle, hard-to-trigger error-handling defect rather than a widely-weaponized bug.

Technical ContextAI

The flaw lives in copy_process() (kernel/fork.c), the core routine backing fork/clone. During task duplication the kernel calls futex_hash_allocate_default() to set up the per-task futex hash; on allocation failure the code jumped to bad_fork_core_free, which calls spin_unlock on tasklist_lock and the target's siglock. At that point in the flow neither lock had been taken, so the unlock operates on locks not held by the current context, producing a locking imbalance (effectively a spurious/double unlock). The correct target, bad_fork_cancel_cgroup, only unwinds cgroup state. CWE is listed as N/A, but the root cause is an improper cleanup / incorrect error handling class defect (akin to CWE-667 improper locking / CWE-460 improper cleanup on error path). Releasing an unheld spinlock corrupts lock ownership assumptions and can leave other CPUs able to enter critical sections concurrently, undermining the integrity of task-list and signal state.

Affected ProductsAI

The affected product is the mainline and stable Linux kernel, specifically builds that include the default futex hash allocation in copy_process() prior to the fix commits. No CPE strings were provided in the intelligence, so exact version ranges are not enumerated in the input; the fix is tracked in the kernel stable tree via commits at https://git.kernel.org/stable/c/4ec3c15462b9f44562f45723a92e2807746ba7d1 and https://git.kernel.org/stable/c/f1635765cd0fdbf27b04d9a50be91a01b5adda13. Distributions rebasing on the affected stable branches (and their downstream kernels) are impacted until they pick up these commits.

RemediationAI

Apply the upstream kernel fix that redirects the error path to bad_fork_cancel_cgroup: Upstream fix available (PR/commit); released patched version not independently confirmed - see https://git.kernel.org/stable/c/4ec3c15462b9f44562f45723a92e2807746ba7d1 and https://git.kernel.org/stable/c/f1635765cd0fdbf27b04d9a50be91a01b5adda13. Operationally, update to the distribution kernel package that incorporates these commits and reboot into the patched kernel. No practical in-place workaround disables the fork error path, but because the trigger is an allocation failure during process creation, reducing memory pressure (adequate RAM/swap sizing, avoiding severe OOM conditions) lowers the chance of reaching the buggy branch - a mitigating, not eliminating, control with the trade-off of not addressing the underlying defect. Restricting untrusted local users' ability to spawn processes under artificial memory pressure (cgroup memory limits, ulimits) also reduces exposure at the cost of application flexibility.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Performance Computing 15 SP7 Not-Affected

Share

CVE-2025-39976 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy