Skip to main content
VulnerabilityPublished Updated

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

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 9.8 Critical · fixed in fcfcba8fe17dbf2c8805690b8cc25e32d81249a4 : patch Linux kernel as a priority.

Data as of 26 Oct 2026, 13:47 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.6% chance of exploitation in 30 days – higher than 50% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in fcfcba8fe17dbf2c8805690b8cc25e32d81249a4, bc70726ddad53c7e9a9a85915bf2415b0d4f42f9, b8a5c0c32df2c5b685ceef76ac77e37c7e1dc3ed +2
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 11 Sep 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 9b7895efac906d66d19856194e1ba61f37e231a4, < fcfcba8fe17dbf2c8805690b8cc25e32d81249a4
Fixed in
  • fcfcba8fe17dbf2c8805690b8cc25e32d81249a4
LinuxLinuxAffected
  • ≥ 9b7895efac906d66d19856194e1ba61f37e231a4, < bc70726ddad53c7e9a9a85915bf2415b0d4f42f9
Fixed in
  • bc70726ddad53c7e9a9a85915bf2415b0d4f42f9
LinuxLinuxAffected
  • ≥ 9b7895efac906d66d19856194e1ba61f37e231a4, < b8a5c0c32df2c5b685ceef76ac77e37c7e1dc3ed
Fixed in
  • b8a5c0c32df2c5b685ceef76ac77e37c7e1dc3ed
LinuxLinuxAffected
  • ≥ 9b7895efac906d66d19856194e1ba61f37e231a4, < aad3129b8e915d0ff492bb7517d825d8490cfdd9
Fixed in
  • aad3129b8e915d0ff492bb7517d825d8490cfdd9
LinuxLinuxAffected
  • ≥ 9b7895efac906d66d19856194e1ba61f37e231a4, < 5e661f55ca8568471fce558effe81cca112f5cb2
Fixed in
  • 5e661f55ca8568471fce558effe81cca112f5cb2
LinuxLinuxAffected
  • =2.6.30
Fixed in–

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

References

Community reviews

Loading reviews…