ext4: detect invalid INLINE_DATA + EXTENTS flag combination
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.4.301, 5.10.246, 5.15.196, 6.1.158, 6.6.114, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
In the Linux kernel, the following vulnerability has been resolved: ext4: detect invalid INLINE_DATA + EXTENTS flag combination syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity file on a corrupted ext4 filesystem mounted without a journal. The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66 Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1 This is an invalid combination since an inode should have either: • INLINE_DATA: data stored directly in the inode • EXTENTS: data stored in extent-mapped blocks Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes. Fix this by detecting this invalid flag combination early in ext4_iget() and rejecting the corrupted inode.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From f19d5870cbf72d4cb2a8e1f749dff97af99b071e · fixed in 4954d297c91d292630ab43ba4d195dc371ce65d3; From f19d5870cbf72d4cb2a8e1f749dff97af99b071e · fixed in f061f7c331fc16250fc82aa68964f35821687217; From f19d5870cbf72d4cb2a8e1f749dff97af99b071e · fixed in 2e9e10657b04152ed0d6ecae8d0c02a3405e28f5; From f19d5870cbf72d4cb2a8e1f749dff97af99b071e · fixed in 1437c95ab2a28b138d4521653583729f61ccb48b; From f19d5870cbf72d4cb2a8e1f749dff97af99b071e · fixed in cb6039b68efa547b676a8a10fc4618d9d1865c23; From f19d5870cbf72d4cb2a8e1f749dff97af99b071e · fixed in de985264eef64be8a90595908f2e6a87946dad34; From f19d5870cbf72d4cb2a8e1f749dff97af99b071e · fixed in 1f5ccd22ff482639133f2a0fe08f6d19d0e68717; From f19d5870cbf72d4cb2a8e1f749dff97af99b071e · fixed in 1d3ad183943b38eec2acf72a0ae98e635dc8456b
- Linux Linux
3.8
- KernelLinux
From 3.8.0 · fixed in 5.4.301; From 5.5.0 · fixed in 5.10.246; From 5.11.0 · fixed in 5.15.196; From 5.16.0 · fixed in 6.1.158; From 6.2.0 · fixed in 6.6.114; From 6.7.0 · fixed in 6.12.55; From 6.13.0 · fixed in 6.17.5
References 8
git.kernel.org
- stable/c/4954d297c91d292630ab43ba4d195dc371ce65d3
- stable/c/f061f7c331fc16250fc82aa68964f35821687217
- stable/c/2e9e10657b04152ed0d6ecae8d0c02a3405e28f5
- stable/c/1437c95ab2a28b138d4521653583729f61ccb48b
- stable/c/cb6039b68efa547b676a8a10fc4618d9d1865c23
- stable/c/de985264eef64be8a90595908f2e6a87946dad34
- stable/c/1f5ccd22ff482639133f2a0fe08f6d19d0e68717
- stable/c/1d3ad183943b38eec2acf72a0ae98e635dc8456b