EXT4: guard directory-entry parsing against out-of-bounds reads on malformed images

[iabdullah215]

What

Add bounds checks to EXT4.EXT4Reader.getDirEntries (in Sources/ContainerizationEXT4/EXT4+Reader.swift) so that a malformed ext4 directory block can no longer drive Data.subdata past the end of the block buffer.

Why

An ext4 image is untrusted input (a distributed / user-supplied rootfs block), so the reader must tolerate hostile on-disk structures. The directory-entry parse loop performed two reads at attacker-controlled offsets without bounds checks:

• The fixed 8-byte entry header was read whenever offset < dirTree.count. A crafted recordLength that advances offset to within 1–7 bytes of the end makes the header read (offset ..< offset + entrySize) run past the block.
• The entry name was read as offset + 8 ..< offset + 8 + nameLength, but nameLength (a UInt8 taken straight from the image) was never validated against the block length, and recordLength was only checked >= entrySize, not >= entrySize + nameLength.

Because Data.subdata(in:) has a precondition on its range, either case traps the process (SIGTRAP) rather than returning an error, i.e. a malformed image is a denial of service against any caller that lists a directory.

Fix

Two guards inside the loop, consistent with the existing recordLength >= entrySize guard (stop parsing the block instead of trapping):

1. offset + entrySize <= dirTree.count before loading the fixed header.
2. recordLength >= entrySize + nameLength and nameStart + nameLength <= dirTree.count before reading the name.

Well-formed images are unaffected: their entries tile the block exactly and always satisfy recordLength >= 8 + nameLength with the name inside the block.

Testing

New Tests/ContainerizationEXT4Tests/TestEXT4Reader+DirEntryBounds.swift:

• wellFormedBlockParsesAllEntries — regression: the guards don't reject valid entries.
• shortHeaderTailDoesNotTrap — header-bounds guard.
• nameLongerThanRecordDoesNotTrap — record-consistency guard.
• nameRunningPastBlockDoesNotTrap — block-bounds guard.

Each of the three malformed-block tests crashes the reader (SIGTRAP) without this change and passes with it; all existing EXT4PathIOTests still pass.

Notes

• getDirEntries was private; it's changed to internal so the test can feed it crafted directory blocks directly. No public API change. Happy to keep it private and instead test via a corrupted on-disk image if preferred.
• The new guards break (lenient, matching the adjacent recordLength guard). If you'd rather surface corruption, they could throw instead, let me know your preference.

Related

• No existing PR/issue addresses this loop directly.
• Nearest miss: Fix the xattr read loop bounds #658 (Fix the xattr read loop bounds) bounded a neighboring read loop in the same reader but left the directory-entry loop unguarded; this PR adds the analogous bounds there.
• Same class of malformed-image reader hardening: Fix a force-unwrap crash on the last leaf of an extent tree #639 (force-unwrap crash on the last extent-tree leaf), Crash instead of silently truncate on a type overflow #663 (crash-instead-of-truncate on type overflow), Match the byte order in the EXT4 reader to how the EXT4 formatter writes data #664 (reader byte-order fix), EXT4: Fix the construction of the path #666 (reader path construction), Remove the incorrect check for visited inodes #659 (visited inodes), Fix a hardlink cycle detection #611 / Fix the hardlink count decrement threshold and unlink cleanup #610 (hardlink cycle / count handling).
• Related symptom reports: [Bug]: EXT4-fs warning (device vdb): ext4_block_to_path:105: block 1710731624 > max in inode 21209237 #441 (EXT4-fs block-out-of-range on a bad image), Fix EXT4 extent offset double-counting causing block address overflow #462 (extent offset overflow).