Cyber Resilience

CVE-2025-40039

Race Condition in Linux Kernel 5.15.145 – 5.16

Published
28 October 2025
Modified
26 February 2026
Patch / advisory
CVSS Score v3.1 4.7
Click a component to see what it means
Raw vectorCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score 0.0013 3th percentile
Risk Priority 35 floored blend · peak EPSS

Summary

CVE-2025-40039 is a medium-severity Race Condition (CWE-362) vulnerability in Linux Linux Kernel. Its CVSS base score is 4.7 (Medium).

Operationally, ranked at the 3th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to AC-3 (Access Enforcement) and SC-39 (Process Isolation) — see the control section below for these in your framework.

OWASP Top 10 for Web (2025)

EU & UK References

Vulnerability Data

In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix race condition in RPC handle list access The 'sess->rpc_handle_list' XArray manages RPC handles within a ksmbd session. Access to this list is intended to be protected by 'sess->rpc_lock'…

more

(an rw_semaphore). However, the locking implementation was flawed, leading to potential race conditions. In ksmbd_session_rpc_open(), the code incorrectly acquired only a read lock before calling xa_store() and xa_erase(). Since these operations modify the XArray structure, a write lock is required to ensure exclusive access and prevent data corruption from concurrent modifications. Furthermore, ksmbd_session_rpc_method() accessed the list using xa_load() without holding any lock at all. This could lead to reading inconsistent data or a potential use-after-free if an entry is concurrently removed and the pointer is dereferenced. Fix these issues by: 1. Using down_write() and up_write() in ksmbd_session_rpc_open() to ensure exclusive access during XArray modification, and ensuring the lock is correctly released on error paths. 2. Adding down_read() and up_read() in ksmbd_session_rpc_method() to safely protect the lookup.

CWE(s)

Related Threats

CVEs Like This One

CVE-2023-1582Same product: Linux Linux Kernel
CVE-2023-52825Same product: Linux Linux Kernel
CVE-2023-52740Same product: Linux Linux Kernel
CVE-2024-40943Same product: Linux Linux Kernel
CVE-2026-23411Same product: Linux Linux Kernel
CVE-2025-38028Same product: Linux Linux Kernel
CVE-2025-21651Same product: Linux Linux Kernel
CVE-2023-53478Same product: Linux Linux Kernel
CVE-2024-53122Same product: Linux Linux Kernel
CVE-2026-46275Same product: Linux Linux Kernel

Affected Assets

linux
linux kernel
5.15.145 — 5.16 · 6.1.71 — 6.2 · 6.3 — 6.6.123

Mitigating Controls

Control response

Prevent
Stop it (NIST 800-53)
Detect
Catch it (NIST detect / respond)

Harden
Shrink the surface (DISA STIG)

Validate
Prove the fix (OWASP ASVS)
  • V10.4.2
  • V10.4.5
  • V15.1.3
  • V15.4.1

Mitigating Controls (NIST 800-53 r5) AI

prevent

Requires that the kernel enforce exclusive (write) access to sess->rpc_handle_list via proper locking before xa_store/xa_erase or xa_load, directly blocking the CWE-362 race.

prevent

Mandates process/thread isolation boundaries that limit the ability of concurrent ksmbd session operations to corrupt or race on the shared XArray.

prevent

Requires memory-protection mechanisms that would block or contain the use-after-free that can result when an unlocked xa_load races with xa_erase on the RPC handle list.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly require proper synchronization primitives and concurrency testing that prevent race conditions.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

detects

Security testing can detect race conditions, but does not prevent them at design or coding time.

prevents

Secure SDLC mandates concurrency controls and synchronization primitives that directly prevent race conditions.

prevents

Application security requirements can specify thread-safety and locking rules, but do not prescribe implementation details.

prevents

Secure architecture principles require proper synchronization and resource isolation, addressing the root cause of CWE-362.

prevents

Secure coding standards explicitly forbid unsafe concurrent access patterns and mandate atomic operations or locks.

none

Change management reduces introduction of concurrency bugs during updates, yet does not address the weakness itself.

References