CVE-2026-43076 in Linux
Summary
by MITRE • 05/06/2026
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: validate inline data i_size during inode read
When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count).
This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory.
In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry()
Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inodes with inline data have i_size <= id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/05/2026
The vulnerability resides within the ocfs2 filesystem implementation in the Linux kernel, specifically addressing a critical flaw in inode validation during disk read operations. This issue demonstrates a classic case of insufficient input validation that can lead to severe memory corruption patterns. The problem manifests when the ocfs2_validate_inode_block() function processes inodes from persistent storage without properly verifying the inline data size constraints, creating a scenario where filesystem corruption can escalate into exploitable conditions.
The technical flaw stems from the absence of validation for the i_size field in relation to inline data capacity during inode processing. When filesystem corruption occurs, an inode's i_size value can become artificially inflated to massive values, such as the reported 1099511627576 bytes representing approximately 1 terabyte, while the actual inline data capacity id_count remains constrained to typical values under 256 bytes. This discrepancy creates a dangerous condition where the ocfs2_dir_foreach_blk_id() iteration function attempts to traverse beyond the allocated inline data buffer boundaries, resulting in memory access violations.
The operational impact of this vulnerability extends beyond simple data corruption to include potential use-after-free conditions that can be leveraged for privilege escalation or system instability. The syzbot report details how an invalid rec_len value of 54648 caused ctx->pos to jump outside the valid memory bounds, ultimately triggering a use-after-free in the ocfs2_check_dir_entry() function. This type of vulnerability aligns with CWE-476 which describes NULL pointer dereferences, and more specifically with CWE-125 which covers out-of-bounds reads, making it particularly dangerous in kernel contexts where such conditions can be exploited to gain unauthorized access to system resources.
The mitigation strategy implemented involves adding a validation check within the ocfs2_validate_inode_block() function to ensure that inodes containing inline data maintain i_size values that do not exceed the id_count capacity limits. This defensive programming approach follows the principle of early validation and failsafe mechanisms, preventing downstream code from operating on corrupted data structures. The fix represents a classic example of applying the principle of least privilege and input sanitization, where the kernel validates data integrity at the earliest possible point in the processing chain rather than allowing corrupted data to propagate through multiple layers of system calls.
This vulnerability demonstrates the critical importance of maintaining data consistency in filesystem implementations, particularly when dealing with metadata structures that are directly read from persistent storage. The solution exemplifies the ATT&CK technique of privilege escalation through kernel exploitation, where memory corruption vulnerabilities are leveraged to execute malicious code with kernel-level privileges. The fix aligns with security best practices for kernel development, emphasizing the need for comprehensive validation of all filesystem metadata during read operations and the implementation of robust error handling that prevents corrupted data from reaching critical system components.