Linux Kernel CVE-2026-90320

Requires the ocfs2 filesystem to be in use and a crafted or corrupted ocfs2 image/volume to be mounted containing an external (non-indexed) xattr block with xh_count/entry offsets exceeding the block, or a malformed indexed xattr bucket. Exploitation is then triggered locally by any listxattr()/getxattr() call against affected files. Limiting factors: it is not remotely reachable, the attacker must control on-disk metadata (typically requiring mount privilege or an auto-mount of an attacker-supplied device, i.e. user interaction to attach the device), and the primary outcome is a kernel crash rather than reliable code execution; systems not using ocfs2 are unaffected.

This is a Linux kernel ocfs2 filesystem bug: ocfs2_validate_xattr_block() validates the block header but never checks that a non-indexed external xattr block's xh_count and entry offsets fit inside the block (and indexed buckets reach list/get consumers after ECC without an entry-bounds check), so listxattr()/getxattr() can walk out-of-range entry arrays or name/value offsets - reproduced as a KASAN out-of-bounds/use-after-free READ in ocfs2_xattr_list_entries. The vendor CVSS is 7.8 with vector AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, but that overstates real risk: this is fundamentally an out-of-bounds READ on attacker-corrupted on-disk metadata, so integrity impact is not realistic (I:N) and the dominant impact is a crash (A:H) with a plausible but secondary information-leak of adjacent kernel memory via the listxattr path (C:L, not C:H). PR:N is also optimistic because the corrupted metadata must be introduced by mounting a crafted/corrupted ocfs2 image, which normally requires mount capability (PR:L). No EPSS score, no CISA KEV listing, and no public exploit are present in the provided data - no public exploit identified at time of analysis - so this is a low-real-world-priority hardening/robustness fix rather than an actively exploited threat, and its footprint is limited to systems using the niche ocfs2 clustered filesystem.

An attacker crafts (or corrupts) an ocfs2 filesystem image with a non-indexed external xattr block whose xh_count/entry offsets exceed the block, or a malformed indexed bucket, and gets it mounted on a target (e.g. a shared cluster volume or an attacker-supplied device). When any process subsequently runs listxattr()/getxattr() on a file, the kernel walks the out-of-range entry array and reads out of bounds, producing a KASAN-detected crash and potentially leaking adjacent kernel memory. No public exploit is identified at time of analysis.