CVE-2026-89492

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

ocfs2: validate directory-index entry counts when reading metadata

ocfs2 validate dx leaf() and ocfs2 validate dx root() check the ECC and signature of an indexed-directory block before it reaches higher-level callers, but neither validator bounds the ocfs2 dx entry list counts against the capacity of the block that holds them.

ocfs2 dx dir search() then walks

for (i = 0; i < le16 to cpu(entry list->de num used); i++)
	dx entry = &entry list->de entries[i];

over de num used entries with no bounds check. entry list is either dx leaf->dl list (from ocfs2 read dx leaf) or, for an inline root, dx root->dr entries. A crafted on-disk image can set de num used (and de count, which is the counted by le() bound of de entries) 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 dx root extent list fields during block read") already bounds dr list for the non-inline dx root, but left the inline dr entries path and the dx leaf dl list unchecked. Add the same read-time validation for both entry lists: de count must equal the capacity of the block (ocfs2 dx entries per leaf()/per root()) and de num used must not exceed de count, rejecting corrupted metadata with -EFSCORRUPTED before ocfs2 dx dir search() can walk an out-of-range entry array.

de count 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).