CVE-2026-74728 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
xfs: handle NULL b_addr in xfs_buf_free
When xfs_buf_alloc_backing_mem() fails, xfs_buf_free() is called with bp->b_addr still NULL. The code falls through to the folio_put path which calls virt_to_folio(NULL), dereferencing an invalid address and causing a kernel crash.
Call Trace: xfs_buf_free+0x25f/0x510 xfs_buf_alloc+0xc98/0x19b0 xfs_buf_find_insert+0x55/0x14d0 xfs_buf_get_map+0x122b/0x17c0 xfbtree_init_leaf_block+0x11c/0x4a0 xfbtree_init+0x1bb/0x460 xrep_rmap_setup_scan+0x100/0x1f0 xrep_rmapbt+0x41/0xc0
Fix this by skipping folio_put() when bp->b_addr is NULL.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability identified in the Linux kernel's XFS filesystem implementation involves a critical null pointer dereference within the buffer management subsystem, specifically during the cleanup phase of memory allocation failures. The issue resides in the xfs_buf_free function, which serves as the primary mechanism for releasing resources associated with an XFS buffer structure when operations fail or complete. Under normal circumstances, this function ensures that allocated backing memory is properly released and reference counts are decremented to prevent resource leaks. However, a specific edge case arises when the initial allocation of backing memory via xfs_buf_alloc_backing_mem fails due to insufficient system resources such as available physical RAM or swap space. In this failure scenario, the buffer pointer bp->b_addr remains NULL because no actual memory was successfully mapped for that buffer object.
The technical flaw occurs because the existing error handling logic in xfs_buf_free does not adequately check whether b_addr is null before proceeding to release associated folio structures. Instead of exiting early or skipping cleanup steps related to allocated memory, the code falls through to a path that invokes virt_to_folio on the bp->b_addr pointer. Since this pointer holds a NULL value at this stage, passing it to virt_to_folio results in an invalid address dereference. This operation attempts to translate a virtual address into a folio structure, which is undefined behavior when applied to a null pointer within kernel space. The immediate operational impact of this flaw is a kernel panic or system crash, effectively causing a denial of service for the entire host operating system. Such crashes can occur during heavy I/O loads or memory-constrained environments where allocation failures are more likely, thereby destabilizing critical server infrastructure that relies on XFS filesystems.
From a classification perspective, this vulnerability aligns with CWE-476, which denotes NULL Pointer Dereference vulnerabilities in software systems. The attack vector is primarily local and requires the ability to trigger memory-intensive operations or exhaust system resources to induce the allocation failure condition. In terms of adversary behavior mapping according to MITRE ATT&CK, this flaw could be leveraged within the context of Denial of Service attacks under techniques such as T1499 Endpoint Denial of Service. An attacker with local access who can manipulate filesystem operations or trigger specific XFS repair routines might exploit this race condition or resource exhaustion scenario to crash the system, disrupting availability and potentially masking other malicious activities behind a reboot cycle.
The mitigation for this issue involves modifying the xfs_buf_free function to include an explicit check for NULL in bp->b_addr before attempting any folio-related cleanup operations. By skipping the call to virt_to_folio when no backing memory was allocated, the kernel avoids dereferencing invalid addresses and prevents the resulting crash. This patch ensures that resource release logic is robust against partial allocation failures where some structures are initialized but others fail. System administrators should apply this kernel update immediately upon availability to restore stability to XFS-dependent environments. Additionally, monitoring for out-of-memory conditions during heavy filesystem operations can help identify systems at risk of triggering this specific code path before the patch is deployed in legacy or unpatched kernels.