EXT2F_INCOMPAT_EXTENTS advertised as supported (EXT2F_INCOMPAT_SUPP) but the entire extents I/O path is EINVAL stubs — every extents-flagged inode (any real ext4 filesystem) fails read/write/truncate after a successful mount, and unlink of extents inodes leaks their blocks
Summary
The mount compatibility check accepts EXT2F_INCOMPAT_EXTENTS (EXT2F_INCOMPAT_SUPP, ext2fs.h:332-337), ext2_ei2i sets IN_E4EXTENTS from the on-disk inode flag, yet ext4_bmapext() is a stub returning EINVAL (:108-111) - so ext2_bmap() fails for every extents inode (:84-86); the write path (ext2_ext_balloc) and truncate (ext2_ext_truncate) are the same stubs. On a stock Linux ext4 image the mount succeeds but every regular file returns EINVAL/EIO on read and write, mmap gets SIGBUS, and unlink leaks the file's blocks (ext2_inactive -> ext2_truncate -> EINVAL). No memory-safety impact (consistent refusal on all paths - no path interprets the i_db[] extent-header overlay as block pointers). Fix: either drop EXTENTS from INCOMPAT_SUPP (refuse at mount with clear diagnostic) or implement the extents path. [VERIFIED pass2: reproduced - real mke2fs ext4 image mounts then all IO EINVAL via the bmapext stub; fix rejects mount rc 71 listing extents unsupported; plain ext2 RO ext3 regression clean]
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-3217 · 5 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 247 B | ↓ raw | |
| fix.diff | — | 714 B | view raw | |
| manifest.json | — | 397 B | view raw | |
| run.log | — | 405 B | view raw | |
| verdict.json | — | 2.0 KB | view raw |
DF-3217 evidence pack
What
EXT2F_INCOMPAT_EXTENTS advertised but every extents I/O path is an EINVAL stub
Verdict
status=reproduced impact=none confidence=certain
See VERDICT.md for the full narrative and fix.diff for the verified fix.
Fix verification
fixedA/B complete: the ext4 image is now rejected at mount (rc=71, console lists extents as unsupported) instead of mounting and failing every I/O; plain ext2 and read-only ext3 still mount (regression clean).
Confirmed kernel references
Detail
Evidence (decisive lines)
VERDICT.md with path:line citations; run.log where a live demo exists; fix.diff
PoC changes
image built on the host (mke2fs -t ext4 + debugfs write), 32MB
Verified recommended fix
remove EXT2F_INCOMPAT_EXTENTS from EXT2F_INCOMPAT_SUPP (mount-time refusal)
Verdict
Reproduced on the stock INVARIANTS guest with a real Linux mke2fs ext4 image (extents flag set, one file hello injected via debugfs): mount -t ext2fs succeeds (EXTENTS is in EXT2F_INCOMPAT_SUPP, ext2fs.h:332-337), then cat/dd/rm of /mnt/hello all fail with EINVAL - ext2_bmap dispatches IN_E4EXTENTS inodes to the ext4_bmapext stub (ext2_bmap.c:84-86 -> :107-111 return (EINVAL);); unlink likewise fails through ext2_ext_truncate. A successful mount of a stock ext4 filesystem is a trap: every regular file is unusable. Post-fix A/B on the F40FIX kernel: the same image is rejected at mount with extents listed as an unsupported optional feature. No memory-safety impact (consistent refusal on all paths).
No comments yet.