CVE-2026-89492

What it actually does

The Linux kernel OCFS2 driver does not bound directory-index entry-list fields (de_num_used and de_count) against the real capacity of dx_leaf and inline dx_root metadata blocks. After a crafted volume is mounted, ocfs2_dx_dir_search() walks an attacker-controlled entry count (up to 0xffff) past the end of a 4KB metadata slab, causing a kernel out-of-bounds read. The read is reachable from ordinary pathname lookup, stat(), or open() on an indexed directory and can disclose adjacent kernel heap or trigger an oops/panic. Integrity of kernel memory is not directly overwritten by this bug; impact is information disclosure and availability.

Why it matters to the business

Hosts that mount OCFS2 volumes—common in Linux clustered storage and shared-disk high-availability designs—can leak kernel memory or crash when a malicious or corrupted volume is attached. Confidentiality of in-kernel data and availability of clustered nodes are the primary business risks. The issue is scored CVSS 9.8, but it is not in CISA KEV, is not tied to ransomware, has no public exploit (maturity none), and has a low, unchanged EPSS (~0.006 over 30 days). Environments that automount SAN, iSCSI, cloud, or cluster LUNs should still patch promptly because a normal directory walk after mount is enough to hit the bug. Disclosure was 33 days ago.

How an attack unfolds

An attacker crafts or tampers with an OCFS2 image so a dx_leaf or inline dx_root block advertises de_num_used and de_count far beyond block capacity. The image is presented as removable media, a cloud or SAN LUN, or a volume from a compromised cluster peer. Once the ocfs2 driver mounts it, any process that looks up, stats, or opens an indexed directory causes ocfs2_dx_dir_search() to iterate off the metadata slab and read kernel heap. Leaked memory may aid later local attacks, or the node may oops. This is a memory-corruption class read, not a remote network worm. No named threat actors, KEV use, or public exploit code are associated with this issue.

How to fix it

Install a Linux kernel that includes the OCFS2 read-time checks: de_count must equal block capacity (ocfs2_dx_entries_per_leaf() or ocfs2_dx_entries_per_root()) and de_num_used must not exceed de_count, with bad metadata rejected as -EFSCORRUPTED before search. Use your distribution’s kernel update that maps this fix (upstream description: ocfs2 validate directory-index entry counts when reading metadata). No product-specific fixed-version list was supplied with this record, so confirm via vendor advisory or kernel changelog. Until patched, do not mount untrusted OCFS2 volumes, restrict who can attach block devices, disable automount of unknown LUNs, and blacklist or unload the ocfs2 module on hosts that do not need clustered OCFS2.

How to confirm the fix worked

Confirm the running kernel’s changelog or vendor advisory lists this OCFS2 directory-index validation as present. On a patched kernel, a well-formed OCFS2 volume mounts and serves directories normally; metadata with mismatched de_count/de_num_used is refused with -EFSCORRUPTED and an OCFS2 error in the kernel log instead of an out-of-bounds access. On hosts that should not use OCFS2, verify the module is not loaded (lsmod, /proc/filesystems). Review recent mounts of type ocfs2 and kernel logs around directory operations for pre-patch oops traces involving ocfs2_dx_dir_search.

Typical attack path

1. Obtain or tamper with an OCFS2 filesystem image so a dx_leaf or inline dx_root block has inflated de_num_used/de_count
2. Present that volume to the target (removable media, SAN/iSCSI/cloud block device, or cluster interconnect)
3. Cause the ocfs2 driver to mount the volume
4. Trigger pathname lookup, stat, or open on an indexed directory
5. Kernel performs an out-of-bounds slab read in ocfs2_dx_dir_search; attacker may observe leaked heap or a node crash

How to detect it

Hunt kernel logs (dmesg, journalctl -k, kdump/vmcore) for oops, KASAN slab-out-of-bounds, or paging-request bugs whose stacks include ocfs2_dx_dir_search, ocfs2_read_dx_leaf, ocfs2_validate_dx_leaf, or ocfs2_validate_dx_root, especially right after an ocfs2 mount. Review audit and syslog for mounts of type ocfs2 from unexpected devices or users. On debug/sanitizer kernels, look for KASAN reports against OCFS2 directory-index objects. There is no public exploit tooling, no named-actor TTP set, and no KEV activity; a pure out-of-bounds read may leave no userspace artifact, so lack of an oops is not proof of non-use. Correlate any matching kernel event with recently attached SAN LUNs, cloud disks, or removable media.

• ocfs2_dx_dir_search
• ocfs2_read_dx_leaf
• ocfs2_validate_dx_leaf
• ocfs2_validate_dx_root
• OCFS2: ERROR
• fstype=ocfs2
• mount.*ocfs2
• KASAN: slab-out-of-bounds in ocfs2_

What your security team should do

• Inventory Linux hosts that load ocfs2 or mount OCFS2 volumes, especially clustered and SAN-backed systems, and patch those kernels first
• Deploy the vendor or upstream kernel that adds directory-index entry-count validation and verify the fix in the changelog
• Until patched, block automount and untrusted LUN attachment; blacklist ocfs2 where unused
• Alert on kernel oops or KASAN stacks naming ocfs2_dx_dir_search, ocfs2_read_dx_leaf, ocfs2_validate_dx_leaf, or ocfs2_validate_dx_root after unexpected ocfs2 mounts
• Limit mount and raw-block-device privileges to administrators; treat untrusted disk images as untrusted input
• Given no KEV listing, no ransomware use, no public exploit, and stable low EPSS, prioritize clustered storage nodes over mass emergency change, but do not defer those nodes