EXT4: guard extent-tree parsing against out-of-bounds reads on malformed images

[iabdullah215]

What

Bounds-check the extent-tree decode in EXT4.EXT4Reader so a malformed inode can no longer drive Data.subdata past the inode's block region. The decode is extracted into an internal decodeExtents(inodeBlock:) helper so it can be unit-tested directly.

Why

An ext4 image is untrusted input. getExtents iterated 0..<entries reading fixed-size records (12 bytes each) with subdata, trusting the entry counts from the on-disk extent headers without checking them against the bytes available:

• The inode block region is only 60 bytes (header + up to four 12-byte records). A depth-0 header claiming >4 leaves, or a depth-1 header claiming >4 indices, makes a read run past the block.
• In the depth-1 path, each leaf block trusts its own header's entries the same way, past the end of the block buffer.

Because Data.subdata(in:) has a precondition on its range, either case traps the process (SIGTRAP) instead of returning an error, a denial of service for any caller that reads a file backed by a crafted inode.

Fix

• Guard every fixed-size read with offset + size <= buffer.count (throwing EXT4.Error.invalidExtents when a header claims more records than fit, i.e. surfacing the corruption rather than silently truncating).
• Fix a latent reversed range when reading a leaf block's header: blockOffset..<extentHeaderSize → blockOffset..<blockOffset + extentHeaderSize (previously benign only because blockOffset == 0 there).

Well-formed images are unaffected: their headers never claim more records than the block holds.

Testing

New Tests/ContainerizationEXT4Tests/TestEXT4Reader+ExtentBounds.swift:

• wellFormedDepth0ExtentsParse — regression: valid depth-0 extents still parse.
• tooManyDepth0EntriesDoesNotTrap — a header claiming 5 leaves in a 60-byte block is rejected (crashes the reader without this change).
• shortInodeBlockReturnsEmpty / nonExtentInodeReturnsEmpty, no-extent cases.

All existing EXT4PathIOTests (which read real files through getExtents) still pass.

Related

• Nearest misses: Fix a force-unwrap crash on the last leaf of an extent tree #639 (Fix a force-unwrap crash on the last leaf of an extent tree) and Fix EXT4 extent offset double-counting causing block address overflow #462 (extent offset double-counting causing block address overflow) hardened other extent-decode failures but did not bound the entry count against the buffer; this PR adds that check.
• Same class of malformed-image reader hardening: Crash instead of silently truncate on a type overflow #663 (crash-instead-of-truncate on type overflow), and the directory-entry bounds fix in a sibling PR on the same reader.
• depth ≥ 2 remains an explicit throw ([Request]: Implement deep extent tree support (depth >= 2) in ContainerizationEXT4 #645 / Add deep extent tree support (depth >= 2) in EXT4 reader #649 / Add deep extent tree support (depth >= 2) in EXT4 formatter #650 track it as a feature); this PR doesn't change that.

[iabdullah215]

@dkovba, mind giving these a look when you have a moment? #848 and #849 have had no CI since Aug 24; fork PRs need a maintainer to approve the workflow run. Both are bounds checks in EXT4+Reader.swift on the untrusted-image parse path, same shape as the xattr loop bounds you fixed in #658: a malformed inode's entries count drives subdata past the end of the block and traps the reader. Tests included in each.