Linux Kernel EUVD-2026-58920

Exploitation requires three concurrent conditions: (1) the target system must be running a vulnerable kernel version (before 6.18.40 or 7.1.5) with the ocfs2 module loaded and an ocfs2 filesystem mounted; (2) a specific inode on that filesystem must already have its embedded extent list corrupted, with l_next_free_rec set to 0 or to a value exceeding l_count - this on-disk corruption is the critical prerequisite and must exist before the vulnerable code path is reachable; (3) a locally-authenticated user with at least low-privilege access (CVSS PR:L) must trigger a write operation against the corrupted file. Systems that do not mount ocfs2 filesystems are entirely unaffected. Systems that mount ocfs2 but have no corrupt inodes will not trigger the bug during normal operation. The requirement for pre-existing on-disk corruption substantially limits opportunistic exploitation and means the scenario is most realistic following hardware storage faults, filesystem inconsistencies, or a separate write-primitive vulnerability targeting block device metadata.

The NVD CVSS score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) is technically consistent with a local, low-privilege path to full kernel-memory impact, but it overstates practical exploitability by assigning AC:L - the on-disk corruption prerequisite is a meaningful additional barrier that AC:L does not capture. In practice, an attacker must first arrange for a specific ocfs2 inode's l_next_free_rec field to be set to an invalid value, which itself typically requires either direct block-device write access (usually needing elevated privileges) or exploitation of a separate vulnerability. EPSS at 0.21% (11th percentile) reflects this constrained profile and aligns with the assessment that this is a stability and integrity issue more likely triggered by hardware fault or misconfiguration than deliberate attack. KEV status is absent and no public exploit code exists, so even a mid-sized municipal IT team in gniezno running ocfs2 cluster nodes should plan this as a routine patch rather than an emergency response. The high C/I/A impact ratings are plausible if kernel memory is corrupted rather than merely panicked, but achieving controlled exploitation beyond denial-of-service on a modern kernel with mitigations (KASLR, SMEP, SMAP) would require substantial additional effort.

A user with local low-privilege access on an ocfs2-mounted system - or a compromised process - manipulates block-device metadata or leverages a separate filesystem corruption path to set an inode's l_next_free_rec to 0. When the same user subsequently performs a write to the affected file, ocfs2_sum_rightmost_rec() computes index i = -1, triggering a UBSAN out-of-bounds access that panics the kernel; on configurations without UBSAN but with lax compiler optimizations, the access may silently corrupt adjacent kernel memory structures, potentially enabling further privilege escalation.