CVE-2026-72211

In the Linux kernel, the following vulnerability has been resolved:

ntfs: grow index root value before reparent header update

ntfs_ir_reparent() moves the resident index root entries into an index

block and leaves a small root stub containing the child VCN. That root

stub can be larger than the existing resident value. For example, an

empty root with value_length 48 has an index area of 32 bytes, while the

large-index root stub needs index_length and allocated_size of 40 bytes.

The current code publishes the larger index.index_length and

index.allocated_size before resizing the resident value. If the resize

returns -ENOSPC, the recovery path can call ntfs_inode_add_attrlist(),

which looks attributes up again while the root header says

allocated_size 40 but the resident value still only provides 32 bytes of

index area. Lookup-time $INDEX_ROOT validation then correctly rejects

that transient layout as corrupt.

This reproduces as a generic/013 failure under qemu. In the failing run,

the transient root had value_len=48, index_size=32, index_length=40, and

allocated_size=40, and ntfsprogs-plus ntfsck reported "Corrupt index

root in MFT record 1177".

When the root stub grows, resize the resident value before publishing the

larger root header. If the resize fails, the old root remains valid for

recovery lookups. Keep the existing header-before-resize ordering for

shrink or same-size cases so the resident value never temporarily

exposes an allocated_size beyond its bounds.