CVE-2026-89492: ocfs2: validate directory-index entry counts when reading metadata

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

ocfs2: validate directory-index entry counts when reading metadata

ocfs2validatedxleaf() and ocfs2validatedxroot() check the ECC and signature of an indexed-directory block before it reaches higher-level callers, but neither validator bounds the ocfs2dxentrylist counts against the capacity of the block that holds them.

ocfs2dxdirsearch() then walks

for (i = 0; i < le16tocpu(entrylist->denumused); i++) dxentry = &entrylist->deentries[i];

over denumused entries with no bounds check. entrylist is either dxleaf->dllist (from ocfs2readdxleaf) or, for an inline root, dxroot->drentries. A crafted on-disk image can set denumused (and decount, which is the countedbyle() bound of deentries) to 0xffff and make the walk read far past the end of the 4KB metadata block, giving a slab out-of-bounds read reachable from any path lookup, stat() or open() on an indexed directory once the image is mounted.

Commit 775c17386a6f ("ocfs2: validate dxroot extent list fields during block read") already bounds drlist for the non-inline dxroot, but left the inline drentries path and the dxleaf dllist unchecked. Add the same read-time validation for both entry lists: decount must equal the capacity of the block (ocfs2dxentriesperleaf()/perroot()) and denumused must not exceed decount, rejecting corrupted metadata with -EFSCORRUPTED before ocfs2dxdirsearch() can walk an out-of-range entry array.

decount is always written as exactly the block capacity when a leaf or inline root is formatted, so the equality check does not reject any valid image.

Found by 0sec automated security-research tooling (https://0sec.ai).