fs/ext: Support INCOMPAT_EXTENTS, RO_COMPAT_DIR_NLINK, RO_COMPAT_HUGE_FILE. #603

2026-07-24T13:50:34Z

Matou1306 commented

2026-07-24 13:50:34 +00:00

Extents writing support.
In addition, the file system can now write to file systems with dir_nlink, as long as the target directory doesn't have the index flag enabled (directories exceeding 64k subdirectories). It also supports huge_file, as long as the huge_file inode flag is not enabled on the file itself (files > 2TB).
This Pull Request depends on #584

What currently works:

Merging a new allocation into the last extent when contiguous (.extentNext fast path)
Adding a new extent entry into an existing leaf/root node that still has room (.addNewExtent)
Creating the very first extent in an empty root (.newExtentRoot)
Checksum maintenance via calc_extent_block_csum on writes to index/leaf blocks
Truncation, including freeing leaves and collapsing an index entry back up the tree (.trim_tree/.trim_index), down to setting currentDepth = 0 when the whole tree empties
Increasing the height of the tree and allocating new leaves.

Extents writing support. In addition, the file system can now write to file systems with dir_nlink, as long as the target directory doesn't have the index flag enabled (directories exceeding 64k subdirectories). It also supports huge_file, as long as the huge_file inode flag is not enabled on the file itself (files > 2TB). This Pull Request depends on #584 What currently works: - Merging a new allocation into the last extent when contiguous (.extentNext fast path) - Adding a new extent entry into an existing leaf/root node that still has room (.addNewExtent) - Creating the very first extent in an empty root (.newExtentRoot) - Checksum maintenance via calc_extent_block_csum on writes to index/leaf blocks - Truncation, including freeing leaves and collapsing an index entry back up the tree (.trim_tree/.trim_index), down to setting currentDepth = 0 when the whole tree empties - Increasing the height of the tree and allocating new leaves.

Matou1306 force-pushed extents from 3bf4e317ca to cf370a4220

2026-08-05 11:56:18 +00:00

Compare

Matou1306 force-pushed extents from fb314654e6 to 69bcdc89f3

2026-08-15 18:47:19 +00:00

Compare

Matou1306 marked the pull request as ready for review 2026-08-15 18:47:53 +00:00

Matou1306 commented

2026-08-15 18:52:08 +00:00

@Burer @dunkaist This PR is finally supposedly complete, please review when you have time and feel free to test it, I will try to post a script or something to easily test soon.

Doczom added the

Subsystem/VFS labels 2026-08-16 21:58:14 +00:00

Burer requested changes

2026-08-19 13:51:51 +00:00

Dismissed

Burer left a comment

🔴 Unbounded tree descent → heap overflow. extfsGetLastLeaf descends via INDEX.nodeBlock and writes 8 bytes per index level into edi, which callers point at EXTFS.extentBreadcrumbs - rb 40, i.e. exactly 5 slots, and the last field of the struct. The descent is bounded only by each node's on-disk currentDepth; there's no depth counter and no check against the 40-byte end. A crafted ext4 image with an index chain deeper than 5 (valid 0xF30A magic, currentDepth != 0) writes past the struct → ring0 heap corruption. Threat model is real: KolibriOS mounts removable media, and any write/delete on an RW-mounted image reaches this via extfsExtendExtent/extfsTruncateExtent.

🟡 entriesMax from disk is trusted without an upper bound. In the ascend path, index nodes read from disk supply entriesMax, and when entriesFolow < entriesMax the code writes [esi + ecx*sizeof.INDEX + …] into the 4 KB block buffer. A forged entriesMax larger than fits in one block writes past tempBlockBuffer. Your own computed entriesMax (Split/CreateLeaf) is fine; the disk-read nodes are not validated.

🔵 The PR description says "up to 4 extents", but the code already does multi-level trees (root split, ascent through index nodes). Please sync the description and state what was actually exercised.

🔵 This PR conflicts with previously merged #584, so update it and relsolve conflict, please.

🔴 **Unbounded tree descent → heap overflow.** `extfsGetLastLeaf` descends via `INDEX.nodeBlock` and writes 8 bytes per index level into `edi`, which callers point at `EXTFS.extentBreadcrumbs` - `rb 40`, i.e. exactly 5 slots, and the last field of the struct. The descent is bounded only by each node's on-disk `currentDepth`; there's no depth counter and no check against the 40-byte end. A crafted ext4 image with an index chain deeper than 5 (valid `0xF30A` magic, `currentDepth != 0`) writes past the struct → ring0 heap corruption. Threat model is real: KolibriOS mounts removable media, and any write/delete on an RW-mounted image reaches this via `extfsExtendExtent`/`extfsTruncateExtent`. 🟡 **`entriesMax` from disk is trusted without an upper bound.** In the ascend path, index nodes read from disk supply `entriesMax`, and when `entriesFolow < entriesMax` the code writes `[esi + ecx*sizeof.INDEX + …]` into the 4 KB block buffer. A forged `entriesMax` larger than fits in one block writes past `tempBlockBuffer`. Your own computed `entriesMax` (Split/CreateLeaf) is fine; the disk-read nodes are not validated. 🔵 The PR description says "up to 4 extents", but the code already does multi-level trees (root split, ascent through index nodes). Please sync the description and state what was actually exercised. 🔵 This PR conflicts with previously merged #584, so update it and relsolve conflict, please.

Matou1306 force-pushed extents from df6c428672 to 344f6bd5af

2026-08-20 12:22:15 +00:00

Compare

Matou1306 commented

2026-08-21 15:36:24 +00:00