CVE-2026-43067
CriticalSummary
A vulnerability in the Linux kernel related to the ext4 filesystem has been resolved, concerning the handling of wraparound when searching for blocks for indirect mapped files. A code change restricts block allocation to numbers fitting within 32-bit block numbers.
Risk Assessment
The vulnerability may allow block allocation beyond the 32-bit limit, posing risks of data corruption or unexpected filesystem behavior. Organizations should be aware of potential data integrity issues.
Recommendation
It is recommended to update the Linux kernel to the latest version that includes fixes for this vulnerability. Additionally, monitor systems for unauthorized block allocations.
Other vulnerabilities in Linux kernel, ext4 filesystem
See all- CVE-2026-45985Medium
A vulnerability has been identified in the ext4 filesystem within the Linux kernel that occurs during block allocation in DIO mode. The issue arises from improper setting of the EXT4_GET_BLOCKS_CONVERT flag, which may lead to stale data problems.
- CVE-2026-45942High
A bitmap inconsistency issue was identified and resolved in the Linux kernel's ext4 filesystem, which occurred during stress tests with large page workloads. This issue was caused by a race condition between page migration and bitmap modification.
- CVE-2026-45920High
A vulnerability has been identified in the Linux kernel related to double decrementing the dirty clusters counter during the ext4 filesystem shutdown. This issue leads to a warning with a value of -1 for the dirty clusters counter, indicating an error in the error handling path.
- CVE-2026-45912Medium
A vulnerability has been identified in the Linux kernel related to the ext4 filesystem, concerning the caching of extents during the splitting process. Caching issues may lead to stale extents remaining in the status tree, resulting in space management errors.
- CVE-2026-45899Medium
In the Linux kernel, a vulnerability in the ext4 filesystem was found where stale extent entries may remain in the extent status tree when splitting an extent fails, leading to data inconsistency.
- CVE-2026-45858Medium
In the Linux kernel, a vulnerability in the ext4 filesystem was found related to incorrect zeroing of allocation ranges when splitting a large unwritten extent. Under certain conditions, when the extent splitting operation fails due to lack of space, stale data may remain in the written range, compromising data integrity.
- CVE-2024-49960High
A vulnerability in the Linux kernel related to the ext4 filesystem has been fixed, concerning use-after-free on failed mount attempts. The issue was that the s_err_report timer remained active, potentially leading to I/O errors.
- CVE-2024-49889High
A vulnerability has been identified in the Linux kernel within the ext4 filesystem that may lead to a use-after-free error in the ext4_ext_show_leaf() function. This issue occurs when the 'path' pointer is used after being freed or reallocated, potentially leading to unpredictable system behavior.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: ext4: handle wraparound when searching for blocks for indirect mapped blocks Commit 4865c768b563 ("ext4: always allocate blocks only from groups inode can use") restricts what blocks will be allocated for indirect block based files to block numbers that fit within 32-bit block numbers. However, when using a review bot running on the latest Gemini LLM to check this commit when backporting into an LTS based kernel, it raised this concern: If ac->ac_g_ex.fe_group is >= ngroups (for instance, if the goal group was populated via stream allocation from s_mb_last_groups), then start will be >= ngroups. Does this allow allocating blocks beyond the 32-bit limit for indirect block mapped files? The commit message mentions that ext4_mb_scan_groups_linear() takes care to not select unsupported groups. However, its loop uses group = *start, and the very first iteration will call ext4_mb_scan_group() wit
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

