Cyber Resilience

CVE-2026-64067

Linux Kernel 6.10 – 7.0.11

Published
19 July 2026
Modified
03 September 2026
Patch / advisory
CVSS Score v3.1 9.8
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score 0.0029 22th percentile
Risk Priority 72 floored blend · peak EPSS

CVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.

Summary

CVE-2026-64067 is a critical-severity Improper Locking (CWE-667) vulnerability in Linux Linux Kernel. Its CVSS base score is 9.8 (Critical).

Operationally, exploitation aligns with the MITRE ATT&CK technique Application or System Exploitation (T1499.004); ranked at the 22th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

EU & UK References

Vulnerability Data

In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing barriers when accessing stream->subrequests locklessly The list of subrequests attached to stream->subrequests is accessed without locks by netfs_collect_read_results() and netfs_collect_write_results(), and then they access subreq->flags without taking…

more

a barrier after getting the subreq pointer from the list. Relatedly, the functions that build the list don't use any sort of write barrier when constructing the list to make sure that the NETFS_SREQ_IN_PROGRESS flag is perceived to be set first if no lock is taken. Fix this by: (1) Add a new list_add_tail_release() function that uses a release barrier to set the pointer to the new member of the list. (2) Add a new list_first_entry_or_null_acquire() function that uses an acquire barrier to read the pointer to the first member in a list (or return NULL). (3) Use list_add_tail_release() when adding a subreq to ->subrequests. (4) Use list_first_entry_or_null_acquire() when initially accessing the front of the list (when an item is removed, the pointer to the new front iterm is obtained under the same lock).

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1499.004 Application or System Exploitation Impact
Adversaries may exploit software vulnerabilities that can cause an application or system to crash and deny availability to users.
T1068 Exploitation for Privilege Escalation Privilege Escalation
Adversaries may exploit software vulnerabilities in an attempt to elevate privileges.
T1499 Endpoint Denial of Service Impact
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users.
T1548 Abuse Elevation Control Mechanism Privilege Escalation
Adversaries may circumvent mechanisms designed to control privilege elevation to gain higher-level permissions.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2024-42085Same product: Linux Linux Kernel
CVE-2024-40972Same product: Linux Linux Kernel
CVE-2024-27010Same product: Linux Linux Kernel
CVE-2024-53086Same product: Linux Linux Kernel
CVE-2023-53233Same product: Linux Linux Kernel
CVE-2023-52498Same product: Linux Linux Kernel
CVE-2024-46750Same product: Linux Linux Kernel
CVE-2025-39791Same product: Linux Linux Kernel
CVE-2026-52946Same product: Linux Linux Kernel
CVE-2025-38359Same product: Linux Linux Kernel

Affected Assets

linux
linux kernel
7.1 · 6.10 — 7.0.11

Mitigating Controls

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 partial match
prevents

Secure SDLC practices directly include code reviews, static analysis, and concurrency standards that prevent improper locking.

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.

prevents

Secure development lifecycle includes concurrency and locking requirements that reduce improper locking defects.

prevents

Application security requirements can mandate proper lock acquisition/release patterns.

prevents

Secure architecture principles address thread-safety and resource synchronization.

prevents

Secure coding standards directly prohibit missing or incorrect lock usage.

finds

Security testing can detect race conditions and locking errors before release.

prevents

Change management may catch locking issues introduced by modifications but does not prevent the weakness itself.

References