CVE-2026-64067 in Linux
Summary
by MITRE • 07/19/2026
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 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).
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability exists in the linux kernel's network filesystem implementation where improper memory ordering leads to potential race conditions when accessing subrequests without proper synchronization mechanisms. The flaw occurs in the netfs subsystem where functions netfs_collect_read_results() and netfs_collect_write_results() traverse the stream->subrequests list without acquiring locks, creating a scenario where memory operations may be reordered by the processor or compiler. The issue specifically manifests when these functions access subreq->flags after obtaining a pointer to a subrequest from the list, but fail to establish proper memory ordering guarantees through barriers.
The technical implementation problem stems from the absence of appropriate memory barriers during list manipulation operations that could allow the NETFS_SREQ_IN_PROGRESS flag to be perceived as set before the subrequest structure is fully initialized or before the list entry is properly linked. This violates the fundamental principles of concurrent programming where proper synchronization must prevent reordering of memory operations that could lead to inconsistent or invalid data states. According to CWE-1164, this represents a weakness in memory ordering that can result in race conditions and undefined behavior in multi-threaded environments.
The operational impact of this vulnerability extends beyond simple data corruption, as it creates potential for privilege escalation and system instability when network filesystem operations are performed concurrently. Attackers could potentially exploit the race condition to manipulate the state of subrequests, leading to incorrect processing decisions, data loss, or even kernel memory corruption that could be leveraged for more severe exploits. The vulnerability affects any system utilizing network filesystems where concurrent read and write operations occur, particularly in high-performance computing environments or server configurations that rely heavily on distributed storage solutions.
The fix implements a comprehensive solution using specialized barrier functions to ensure proper memory ordering throughout the list operations. The new list_add_tail_release() function incorporates release barriers when adding entries to the list, ensuring that all prior memory stores complete before the new list entry becomes visible to other threads. Meanwhile, list_first_entry_or_null_acquire() uses acquire barriers when reading from the list head, preventing subsequent memory loads from being reordered before the pointer access. These modifications directly address the requirements of ATT&CK technique T1068 by mitigating improper privilege escalation opportunities through memory safety vulnerabilities, and align with CWE-1164's recommendations for proper memory ordering in concurrent systems. The solution ensures that when subrequests are added to or removed from the list, all memory operations maintain their intended sequence, preventing the race condition that could lead to inconsistent flag states and incorrect operational behavior.