Linux Kernel EUVD-2026-66446

Exploitation requires a local authenticated session with at least low-privilege credentials (PR:L per CVSS vector). The target system must be running the XFS filesystem - systems using ext4, btrfs, or other filesystems are unaffected. The attacker must be able to trigger execution of the xrep_tempfile_create code path within the XFS online scrub/repair subsystem, which is typically invoked by xfs_scrub or kernel-internal repair routines. Specifically, the failure branch after sc->tempip assignment must be reached, requiring a controlled or race-conditioned error during tempfile creation. The non-default and administratively-oriented nature of XFS scrub operations limits opportunistic triggering compared to always-reachable syscall surfaces. Remote exploitation is not possible given AV:L.

The NVD CVSS 7.8 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) signals a credible local privilege escalation path accessible to any low-privilege user, with full confidentiality, integrity, and availability impact upon successful exploitation. The AC:L rating may be optimistic given that triggering the specific failure branch in xrep_tempfile_create after sc->tempip is set likely requires arranging a controlled error condition during XFS scrub - this adds practical complexity not reflected in AC:L. No EPSS score was provided, this CVE is not listed in the CISA KEV catalog, and no public proof-of-concept has been identified, which lowers the immediate threat posture. Real-world exploitability is further constrained by the requirement for XFS filesystem usage and access to the scrub/repair codepath. Multi-tenant environments running RHEL (which defaults to XFS since version 7) represent the highest-risk deployment scenario. The risk is genuine but not immediately critical without KEV or POC signals.

A local user with a standard unprivileged shell on an XFS-backed Linux system invokes or triggers the XFS online repair scrub path, causing xrep_tempfile_create to fail after sc->tempip has been assigned. The attacker then times a memory allocation to reclaim the freed inode slab region and uses the dangling sc->tempip pointer - when subsequently dereferenced by kernel repair code - to corrupt kernel memory structures, enabling privilege escalation to root. No public proof-of-concept exists at time of analysis.