Linux Kernel CVE-2026-90321

Requires the OCFS2 filesystem to be built/enabled and a crafted or corrupted OCFS2 image to be mounted on the target, then any xattr read (getxattr/listxattr) performed on the malicious inode with inline xattrs. Limiting factors: the attacker must supply the malicious on-disk metadata and have it mounted, which normally requires local privilege (CAP_SYS_ADMIN) or an automount/removable-media path that mounts untrusted images; the CVSS vector confirms local attack vector (AV:L) and required user interaction (UI:R, i.e. a victim mounts/reads the image). It is not remotely exploitable and does not affect default configurations that never mount untrusted OCFS2 volumes.

This is a memory-safety flaw in the Linux kernel OCFS2 filesystem: inode-block validation never bounds-checked inline xattr entry name/value offsets, so corrupted inline xattr metadata lets getxattr()/listxattr() walk past the inline storage, producing a KASAN use-after-free READ (2 bytes) in ocfs2_xattr_find_entry(). The vendor CVSS is 7.8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), but the signals conflict with the technical facts: the fix and the reproducer both indicate an out-of-bounds/UAF READ triggered by mounting a crafted/corrupted OCFS2 image and then reading xattrs - a read primitive is crash-primary with at most a marginal 2-byte information leak, so C:H/I:H/A:H overstates confidentiality and integrity impact. PR:N is also optimistic: producing the corrupted metadata requires the attacker to supply a malicious filesystem image and have it mounted, which normally needs CAP_SYS_ADMIN (or a removable-media automount path), i.e. PR:L. There is no EPSS score, no CISA KEV listing, and no public exploit; combined with OCFS2's niche footprint, real-world risk is low-to-moderate and far below the headline 7.8. Net: a legitimate hardening fix against corrupted on-disk metadata, not an urgent remotely-exploitable priority.

An attacker crafts an OCFS2 image with corrupted inline xattr metadata (out-of-range entry name/value offsets) and gets it mounted on a target host - e.g. via a USB stick that is automounted, or a shared/attacker-controlled block device. When any user or process subsequently calls getxattr()/listxattr() on the malicious inode, the kernel walks past the inline storage, causing an out-of-bounds/use-after-free read that panics the kernel or leaks small amounts of adjacent memory. No public exploit code has been identified at time of analysis.