In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing barriers when accessing stream->subrequests locklessly The… (CVE-2026-64067)
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).
AI Analysis
Technical Summary
The Linux kernel netfs subsystem had a concurrency issue where the list of subrequests (stream->subrequests) was accessed locklessly without proper memory barriers. Functions netfs_collect_read_results() and netfs_collect_write_results() read subreq->flags without an acquire barrier after obtaining the subreq pointer, while the list construction functions lacked a release barrier to ensure the NETFS_SREQ_IN_PROGRESS flag was visible before the pointer was published. The fix involved adding list_add_tail_release() and list_first_entry_or_null_acquire() functions to enforce release and acquire memory barriers respectively, and using these functions when adding to and accessing the subrequests list to ensure correct synchronization.
Potential Impact
Without proper memory barriers, concurrent access to the subrequests list could result in reading stale or inconsistent data, potentially causing incorrect behavior in the netfs subsystem. However, no specific exploitation details or impact such as privilege escalation or denial of service are provided.
Mitigation Recommendations
A fix has been implemented in the Linux kernel by adding memory barrier functions and using them appropriately in netfs code. Users should apply the updated kernel version containing this fix. Patch status is not explicitly confirmed in the provided data; check the vendor or Linux kernel advisories for the exact fixed versions and update accordingly.
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing barriers when accessing stream->subrequests locklessly The… (CVE-2026-64067)
Description
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).
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel netfs subsystem had a concurrency issue where the list of subrequests (stream->subrequests) was accessed locklessly without proper memory barriers. Functions netfs_collect_read_results() and netfs_collect_write_results() read subreq->flags without an acquire barrier after obtaining the subreq pointer, while the list construction functions lacked a release barrier to ensure the NETFS_SREQ_IN_PROGRESS flag was visible before the pointer was published. The fix involved adding list_add_tail_release() and list_first_entry_or_null_acquire() functions to enforce release and acquire memory barriers respectively, and using these functions when adding to and accessing the subrequests list to ensure correct synchronization.
Potential Impact
Without proper memory barriers, concurrent access to the subrequests list could result in reading stale or inconsistent data, potentially causing incorrect behavior in the netfs subsystem. However, no specific exploitation details or impact such as privilege escalation or denial of service are provided.
Mitigation Recommendations
A fix has been implemented in the Linux kernel by adding memory barrier functions and using them appropriately in netfs code. Users should apply the updated kernel version containing this fix. Patch status is not explicitly confirmed in the provided data; check the vendor or Linux kernel advisories for the exact fixed versions and update accordingly.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-f3mp-m5hm-h688
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64067"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27a92a4a8d598912c252
Added to database: 07/19/2026, 19:38:17 UTC
Last enriched: 07/19/2026, 19:52:36 UTC
Last updated: 07/20/2026, 19:41:22 UTC
Views: 11
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.