CVE-2026-74723 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
btrfs: lzo: reject inline extents without valid headers
[BUG]
For a crafted btrfs image, the following KASAN can be triggered when reading an inline lzo compressed file extent:
BUG: KASAN: slab-out-of-bounds in lzo_decompress+0x57d/0x700 Read of size 4 at addr ffff888006f2e644 by task btrfs_lzo_inlin/77
Call Trace: <TASK> dump_stack_lvl+0x5b/0x70 print_report+0xd1/0x610 kasan_report+0xe0/0x110 __asan_report_load_n_noabort+0x13/0x20 lzo_decompress+0x57d/0x700 btrfs_decompress+0x140/0x1c0 uncompress_inline+0x147/0x1b0 btrfs_get_extent+0xb23/0x10a0 btrfs_do_readpage.constprop.0+0x538/0x1ac0 btrfs_readahead+0x32f/0x5f0 read_pages+0x16f/0x850 page_cache_ra_unbounded+0x296/0x490 do_page_cache_ra+0xd9/0x130 page_cache_sync_ra+0x3ee/0x6f0 filemap_get_pages+0x306/0x15c0 filemap_read+0x329/0xd00 btrfs_file_read_iter+0x1f8/0x2b0 vfs_read+0x4ef/0x720 ksys_read+0xf8/0x1d0 __x64_sys_read+0x71/0xb0 x64_sys_call+0x1ab0/0x1b70 do_syscall_64+0x61/0x470 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK>
[CAUSE]
For an inline lzo compressed file extent, there should always be one lzo header, recording the total length of the compressed data, followed by one segment header, recording the compressed lzo payload.
But if a crafted inline lzo compressed file extent contains only an lzo header, without the segment header or payload, lzo_decompress() will still try to read the segment header, causing a read beyond the item boundary.
Furthermore if the inline lzo compressed file extent is the first item of the leaf, it will be at the extent buffer boundary. The above out-of-boundary read will go beyond the extent buffer boundary, triggering the above KASAN report.
[FIX]
Validate the total length of the inlined lzo compressed file extent, to make sure there is at least one LZO header and one segment header, and a non-zero payload.
[ Rework the commit message to remove slop ]
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel's Btrfs filesystem implementation contains a critical input validation flaw within its LZO compression decompression routine that allows for out-of-bounds memory reads when processing maliciously crafted file images. This vulnerability, identified as CVE-2024-something corresponding to the fix rejecting inline extents without valid headers, stems from an insufficient boundary check in the lzo_decompress function. When Btrfs attempts to read a file extent marked as LZO compressed and stored inline within the metadata leaf structure, it assumes that the data block contains both the standard LZO header describing the total length of the compressed stream and at least one segment header containing the actual payload. However, if an attacker constructs a Btrfs image where such an inline extent is truncated or malformed to contain only the initial LZO header without the subsequent segment header or any payload data, the decompression logic proceeds unchecked. The function attempts to read past the end of the allocated buffer to retrieve these missing structural elements, resulting in a slab-out-of-bounds memory access as detected by Kernel Address Sanitizer (KASAN).
The technical root cause lies in the lack of rigorous length validation prior to initiating the decompression process for inline extents. In Btrfs, inline extents are stored directly within the leaf nodes rather than pointing to separate data blocks on disk. This architectural choice means that these extents are tightly packed and their boundaries must be strictly respected by all reading functions. The specific failure occurs because the code does not verify that the total length of the item is sufficient to accommodate both the LZO header and at least one segment header before calling lzo_decompress. Consequently, when the pointer arithmetic advances beyond the valid data range defined by the extent's declared size, it accesses memory outside the allocated slab object. This behavior classifies as CWE-125 Out-of-bounds Read, a classic category of vulnerability where software reads data past the end or before the beginning of the intended buffer.
The operational impact of this flaw is significant due to its potential for information disclosure and system instability. An attacker who can influence the contents of a Btrfs filesystem image, such as through a shared storage volume or by tricking an administrator into mounting a malicious disk image, could trigger this out-of-bounds read. While KASAN reports indicate a memory safety violation rather than immediate code execution, in production kernels without debug sanitizers enabled, such reads can lead to the leakage of sensitive kernel memory contents to user space via subsequent system calls like vfs_read and btrfs_file_read_iter. Furthermore, depending on how the accessed memory is utilized or if the read triggers a page fault that leads to further corruption, this could potentially be leveraged for denial-of-service attacks causing kernel panics or crashes. The vulnerability affects the file reading path specifically, meaning it requires an active user process attempting to open and read files from the compromised filesystem, placing it within the context of local privilege escalation vectors if combined with other flaws, though primarily it serves as a robustness issue against malformed inputs.
From a threat modeling perspective aligned with MITRE ATT&CK, this vulnerability relates to techniques involving invalid input handling that can lead to system crashes or information gathering. It falls under the broader category of software vulnerabilities that compromise integrity and availability. The attack vector is technically local but requires physical or logical access to modify filesystem images prior to mounting them on a target Linux system. This makes it particularly relevant in scenarios involving removable media, virtual machine disk images, or network-attached storage where image integrity cannot be fully trusted by the host kernel without additional verification layers.
To mitigate this risk, users should ensure their systems are updated with the latest stable kernels that include the patch validating inline LZO extent lengths. The fix explicitly adds checks to verify that an inline compressed file extent contains at least one valid LZO header and one segment header with a non-zero payload length before attempting decompression. Administrators managing Btrfs volumes, especially those exposed to untrusted sources such as cloud storage snapshots or user-uploaded archives mounted via loop devices, should prioritize applying this update. Additionally, enabling KASAN in development environments can help detect similar boundary violations during testing phases of custom filesystem drivers or applications interacting with block devices. Regular auditing of file system images for structural integrity and avoiding the mounting of unverified disk images remain essential operational security practices to prevent exploitation of such low-level kernel memory safety issues.