CVE-2026-43153

What it actually does

This is a local Linux kernel use-after-free flaw in XFS extended-attribute handling. The vulnerable logic around xfs_attr_leaf_hasname() could return a pointer to a buffer that had already been released when lower-level XFS attribute lookup functions failed in certain ways. Subsequent callers could then operate on stale kernel memory, creating a memory-corruption condition in kernel context. Because exploitation occurs inside the kernel, successful abuse could allow a local, low-privileged user or process to crash the system, corrupt data, or potentially escalate privileges depending on kernel configuration, allocator behavior, and exploit reliability.

Why it matters to the business

Systems using affected Linux kernel versions with XFS filesystems may be exposed to local privilege escalation or denial-of-service risk. The practical threat is highest on multi-user Linux servers, shared hosting, developer workstations, container hosts where local users or workloads can interact with XFS-backed storage, and systems that allow untrusted users to create or manipulate extended file attributes. The CVSS score is high, but the current EPSS is very low at 0.00138 with no 30-day increase, there is no CISA KEV listing, no ransomware association, and no public exploit maturity reported, so urgency should be driven primarily by kernel exposure, local-user risk, and normal patch windows rather than active widespread exploitation.

How an attack unfolds

An attacker first needs local code execution or an authenticated local account on a system running an affected Linux kernel and using XFS. The attacker then performs filesystem operations that exercise XFS extended-attribute lookup and update paths, attempting to trigger an error condition where the attribute lookup code releases an internal buffer but returns a non-NULL stale pointer to the caller. If the stale pointer is later reused, the kernel can dereference or manipulate freed memory. In the simplest outcome, this can produce a kernel oops, panic, or filesystem instability. With deeper kernel exploitation work, an attacker may attempt to shape heap allocations after the free and before reuse so the stale pointer references attacker-influenced data, potentially converting the bug into privilege escalation. There are no known named threat actors, KEV evidence, or mature public exploit reports associated with this vulnerability as provided.

How to fix it

Upgrade to a Linux kernel version that includes the upstream XFS fix removing the unsafe xfs_attr_leaf_hasname() calling pattern and ensuring callers release buffers correctly after xfs_attr3_leaf_read(). Because no exact fixed versions were provided, use vendor-specific kernel advisories and package repositories for the authoritative fixed kernel build for each distribution. Prioritize patching systems with XFS filesystems that allow local user access, shared workloads, or untrusted code execution. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling or isolating services that allow arbitrary filesystem writes to XFS-backed paths, enforcing least privilege, and using mandatory access controls such as SELinux or AppArmor. Mitigations should be treated as temporary because the vulnerable code is in kernel filesystem handling.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the vendor-fixed version for the distribution, not merely installed but not yet booted. Check with commands such as uname -r and the platform package manager, then compare against the vendor security advisory for this issue. Confirm whether XFS is in use with findmnt -t xfs, mount, or lsblk -f. Review kernel changelogs or vendor patch notes for the XFS fix referencing removal or open-coding of xfs_attr_leaf_hasname() and corrected buffer release handling. After patching, reboot into the fixed kernel and confirm no affected kernel remains active. For high-assurance validation, run regression tests that exercise XFS extended-attribute operations on non-production systems and monitor dmesg or journalctl -k for kernel warnings, XFS errors, KASAN reports, oopses, or panics.

Typical attack path

1. Gain local access to a Linux system running an affected kernel, such as through a shell account, compromised service account, container escape prerequisite, or existing foothold.
2. Identify that the target uses XFS for a writable filesystem path and that the attacker can create files or manipulate extended attributes there.
3. Trigger XFS extended-attribute operations that reach the vulnerable lookup and error-handling path.
4. Cause the kernel to reuse a released XFS buffer pointer after an error return from the internal attribute lookup routine.
5. Leverage the resulting memory corruption to crash the host or, with a reliable exploit, attempt kernel privilege escalation.
6. Use elevated privileges, if achieved, to disable controls, access sensitive data, install persistence, or pivot further.

How to detect it

There is no single reliable network indicator for this vulnerability because exploitation is local and occurs inside kernel XFS filesystem code. To investigate possible prior exploitation, review kernel logs from journalctl -k, dmesg archives, /var/log/kern.log, /var/log/messages, crash dump infrastructure, and EDR telemetry for kernel oopses, panics, KASAN reports, slab allocator warnings, or XFS errors around extended-attribute activity. Correlate crash times with local user sessions, sudo activity, container workload starts, CI jobs, file creation bursts, and commands that manipulate extended attributes such as setfattr, getfattr, attr, rsync with xattrs, backup tools, or security labeling operations. Look for repeated crashes or warnings on XFS-mounted paths initiated by low-privileged accounts. If crash dumps are available, examine stack traces for XFS attribute functions such as xfs_attr_leaf_hasname, xfs_attr3_leaf_read, xfs_attr3_leaf_lookup_int, xfs_attr_set, or xfs_attr_get. Absence of these artifacts does not prove non-exploitation, because a successful privilege-escalation attempt may leave limited forensic evidence beyond normal local process execution and kernel memory corruption side effects.

• BUG: KASAN: use-after-free
• use-after-free in xfs_attr_leaf_hasname
• xfs_attr_leaf_hasname
• xfs_attr3_leaf_read
• xfs_attr3_leaf_lookup_int
• xfs_attr_set
• xfs_attr_get
• XFS internal error
• XFS: Assertion failed
• kernel BUG at fs/xfs
• Oops:
• Kernel panic - not syncing
• general protection fault
• slab-use-after-free
• setfattr
• getfattr

What your security team should do

• Inventory Linux systems using XFS and identify those that permit local users, shared workloads, CI jobs, containers, or untrusted code execution.
• Map each affected system to its distribution kernel advisory and schedule upgrade to the fixed kernel build, prioritizing multi-user and externally exposed workload hosts.
• Reboot patched systems and verify the running kernel version, since kernel package installation alone does not remediate the active kernel.
• Temporarily reduce local attack surface by limiting shell access, restricting write access to XFS-backed shared paths, and isolating untrusted workloads until patching is complete.
• Enable and review kernel logging for XFS errors, oopses, panics, KASAN use-after-free reports, and suspicious extended-attribute activity.
• Treat unexplained kernel crashes on XFS systems as potentially security-relevant until investigated, especially if they follow activity by low-privileged users.
• Track EPSS, exploit maturity, and CISA KEV status for changes; current provided signals show low exploitation likelihood and no known active exploitation, but kernel local privilege escalation bugs can become more practical after public patch analysis.