CVE-2025-38243 in Linux
Summary
by MITRE • 07/09/2025
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix invalid inode pointer dereferences during log replay
In a few places where we call read_one_inode(), if we get a NULL pointer we end up jumping into an error path, or fallthrough in case of __add_inode_ref(), where we then do something like this:
iput(&inode->vfs_inode);
which results in an invalid inode pointer that triggers an invalid memory access, resulting in a crash.
Fix this by making sure we don't do such dereferences.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 05/02/2026
The vulnerability described in CVE-2025-38243 represents a critical memory safety issue within the Linux kernel's btrfs file system implementation. This flaw manifests during log replay operations when the kernel attempts to process inode references, creating a scenario where invalid memory access can occur due to improper pointer handling. The vulnerability specifically affects the btrfs file system's ability to correctly manage inode references during recovery operations, potentially leading to system instability and crashes.
The technical root cause of this vulnerability lies in the improper handling of NULL pointer return values from the read_one_inode() function call within the btrfs log replay mechanism. When this function returns a NULL pointer, the kernel code does not adequately validate this condition before proceeding with operations that attempt to dereference the inode pointer. The problematic code path involves a fallthrough scenario in __add_inode_ref() function where the code continues execution without proper NULL checks, ultimately executing iput(&inode->vfs_inode) on what may be an invalid pointer. This pattern directly violates fundamental memory safety principles and creates a clear path for kernel memory corruption.
The operational impact of this vulnerability extends beyond simple system crashes to potentially enable privilege escalation or denial of service conditions within systems utilizing btrfs file systems. Attackers who can manipulate the conditions leading to log replay operations may exploit this vulnerability to cause system panics or potentially gain elevated privileges through controlled memory corruption. The vulnerability affects systems running Linux kernels with btrfs file system support, particularly those undergoing log replay operations such as during system recovery or journal replay scenarios, making it a significant concern for enterprise and server environments that rely on btrfs for data storage.
This vulnerability aligns with CWE-476, which addresses NULL pointer dereference issues in software implementations, and demonstrates poor error handling practices in kernel space code. The flaw also relates to ATT&CK technique T1068, which involves exploiting local privileges to gain system-level access through kernel vulnerabilities. The improper handling of error conditions in kernel space creates opportunities for attackers to escalate privileges or cause system instability through carefully crafted file system operations that trigger the problematic code path during log replay processes. Organizations should prioritize patching this vulnerability immediately, particularly those running btrfs file systems in production environments where log replay operations may occur during system maintenance or recovery scenarios.
The fix for this vulnerability requires implementing proper NULL pointer validation before any inode pointer dereferences occur during log replay operations. This involves ensuring that all code paths following read_one_inode() calls properly check for NULL return values and handle these conditions appropriately without attempting to dereference invalid pointers. The implementation should follow established kernel programming practices for error handling and memory management, ensuring that resources are properly managed and that invalid pointers never reach the point where they can cause memory access violations. This type of vulnerability demonstrates the critical importance of defensive programming in kernel space code and the need for comprehensive testing of error conditions in file system implementations.