CVE-2026-72377 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints
Regular AFS files correctly use afs_file_aops which have release_folio set as netfs_release_folio, so AS_RELEASE_ALWAYS is valid for them when fscache is enabled (set via afs_vnode_set_cache()). Symlinks and mountpoints in AFS use afs_dir_aops, which does not provide a release_folio callback. However, afs_apply_status() unconditionally calls mapping_set_release_always() for these.
In such case when memory management code attempts to release folios, filemap_release_folio() checks folio_needs_release() which returns true due to AS_RELEASE_ALWAYS being set. Since there is no release_folio callback, it falls through to try_to_free_buffers(), which at present expects buffer_heads to be not null. For symlinks and mountpoints without buffer_heads, this causes pointer dereference.
[dh: Added more bits that were missed]
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability described represents a critical memory management flaw in the Linux kernel's Andrew File System (AFS) implementation that stems from improper handling of the AS_RELEASE_ALWAYS flag for specific AFS object types. This issue affects the kernel's file system cache subsystem and demonstrates a fundamental mismatch between memory management expectations and actual data structure capabilities within the AFS module. The problem manifests when the kernel attempts to release folios associated with symbolic links and mount points in AFS, creating a scenario where memory cleanup operations fail catastrophically due to missing callback implementations.
The technical root cause lies in the inconsistent application of the AS_RELEASE_ALWAYS flag across different AFS object types within the kernel's address space management system. Regular AFS files properly utilize afs_file_aops which correctly implement netfs_release_folio as their release_folio callback, making AS_RELEASE_ALWAYS appropriate for these objects when fscache is enabled through afs_vnode_set_cache(). However, symlinks and mountpoints in AFS employ afs_dir_aops which lack any release_folio callback implementation. The afs_apply_status() function unconditionally applies mapping_set_release_always() to all AFS objects regardless of their specific type or callback capabilities, creating a dangerous mismatch between flag setting and actual implementation.
When memory management code attempts to release folios for these improperly configured objects, the filemap_release_folio() function performs a folio_needs_release() check that returns true due to AS_RELEASE_ALWAYS being set. The system then attempts to execute the release operation through try_to_free_buffers(), which assumes buffer_heads are present and non-null. This assumption fails spectacularly for symlinks and mountpoints that do not maintain buffer_head structures, resulting in a null pointer dereference that can crash the kernel or create exploitable conditions. This vulnerability directly relates to CWE-476 Null Pointer Dereference and represents a classic case of improper resource management where kernel memory subsystems operate under incorrect assumptions about object capabilities.
The operational impact of this vulnerability extends beyond simple system instability to potentially enable privilege escalation attacks, as demonstrated by the ATT&CK framework's T1068 Abuse of Job Scheduling and T1543 Create or Modify System Process categories. The flaw exists in kernel space where memory corruption can be leveraged to gain elevated privileges or cause denial of service across the entire system. System administrators face significant risk when AFS is deployed, particularly in environments where these file types are actively used, as the vulnerability can be triggered through normal file operations without requiring special privileges or complex attack vectors.
Mitigation strategies should focus on immediate kernel updates that address the specific inconsistency in flag application and callback implementation. The fix requires modifying afs_apply_status() to properly differentiate between AFS object types and only set AS_RELEASE_ALWAYS for objects that actually provide release_folio callbacks. System administrators should prioritize patching affected kernel versions and consider implementing monitoring for abnormal memory management operations in environments where AFS is active. Additionally, security teams should review current AFS deployments to identify potential exposure windows and implement appropriate network segmentation measures while awaiting official patches. The vulnerability highlights the importance of maintaining strict consistency between kernel subsystem interfaces and their underlying implementations, particularly in memory management areas where incorrect assumptions can lead to complete system compromise rather than simple service disruption.