CVE-2026-31686

What it actually does

This is a Linux kernel memory-management flaw in KASAN page-table shadow cleanup. The vulnerable code assumes that page-table descriptor memory is always aligned as a full struct page, but on some architectures and page-size configurations, such as PowerPC with 64K pages, page-table objects may be allocated from slab caches instead. When persistent memory or similar memory mappings are removed, the kernel can free the wrong address or free the same page-table backing object twice, causing heap corruption. Because this occurs in kernel memory-management code, the practical impact can range from a kernel panic or denial of service to potential local privilege escalation if an attacker can reliably trigger and shape the memory corruption. The CVSS vector indicates local access with low privileges and no user interaction, with high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could allow a local user or process to crash affected Linux systems or potentially gain elevated kernel-level privileges, which can disrupt workloads, compromise sensitive data, and undermine host isolation. The issue is most relevant to systems running affected Linux kernels with the vulnerable KASAN memory-management code path, especially architectures and configurations where page-table allocations are slab-backed rather than full-page aligned. It is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no public exploit maturity reported, and has a very low and flat EPSS score, so broad internet-scale exploitation is unlikely; however, kernel local privilege escalation and crash bugs should still be prioritized on multi-user, shared, high-availability, or production infrastructure.

How an attack unfolds

An attacker first needs local code execution on an affected Linux host. They then attempt to reach the vulnerable memory-unmapping path by causing creation and removal of memory mappings that exercise KASAN page-table shadow cleanup, such as workflows involving persistent memory device mapping, unbinding, or memory hot-remove style operations. On vulnerable architecture and kernel configurations, kasan_free_pxd() may compute the object to free using page-based alignment assumptions that do not match the actual slab allocation. During cleanup, the kernel may attempt to free an already-freed or incorrect slab object, producing double-free memory corruption. In the simplest outcome, this triggers a KASAN report, kernel taint, oops, panic, or system instability. A more capable attacker would try to groom kernel heap allocations around the double-free to convert the corruption into controlled kernel memory modification and privilege escalation. There are no named threat actors, KEV listing, or public exploit maturity associated with this issue in the provided intelligence.

How to fix it

Upgrade to a Linux kernel version or distribution kernel package that includes the upstream fix for the KASAN page-table descriptor free logic. No exact fixed package versions were provided, so use the security advisory and errata from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer. Where immediate patching is not possible, reduce exposure by restricting local shell access, limiting access to privileged device-management operations such as persistent memory management and sysfs driver unbind operations, removing unnecessary persistent memory tooling from untrusted hosts, and enforcing least privilege for users and services. Because this is a kernel memory-corruption issue, mitigations should be treated as temporary; the durable fix is to deploy a patched kernel and reboot into it.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that contains the fix, not merely that packages were installed. Validate with commands such as `uname -a`, distribution package queries, and vendor advisory mapping for the deployed kernel build. On source-built kernels, confirm the KASAN page-table cleanup change is present in the mm/kasan code path and that kasan_free_pxd() uses the page-table start address rather than deriving a virtual address from pxd_page() in the vulnerable manner. Reboot after patching and verify the active kernel is the fixed kernel. For exposure validation, review whether affected architectures, KASAN-enabled kernels, persistent memory, memory hotplug, or similar mapping teardown paths are present. If safe in a test environment only, reproduce the previously failing PMEM mapping/unmapping workflow and confirm there are no KASAN double-free reports, kernel oopses, or slab invalid-free messages.

Typical attack path

1. Gain local execution on an affected Linux system, typically as an unprivileged or low-privileged user.
2. Identify whether the host runs a vulnerable kernel, architecture, page-size configuration, and memory-management configuration that can reach the affected KASAN page-table cleanup path.
3. Trigger creation and teardown of relevant memory mappings, such as persistent memory or device-backed memory mappings that call into memunmap_pages() and KASAN shadow removal.
4. Cause kasan_remove_zero_shadow() and kasan_free_pxd() to process a page-table descriptor whose allocation is not full-page aligned.
5. Induce an invalid free or double free in kernel slab/page-table memory.
6. Use the resulting condition to crash the kernel, or attempt kernel heap grooming to turn the memory corruption into privilege escalation.

How to detect it

Look for evidence of attempted or successful triggering in kernel logs, persistent logs, crash dumps, audit logs, and EDR telemetry. Useful sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `journalctl -k`, kernel crash dump directories, pstore/ramoops, auditd records for sysfs writes, and process execution logs for memory-management tooling such as `ndctl`. Focus on KASAN reports showing double-free or invalid-free events in `kasan_remove_zero_shadow`, `kasan_free_pxd`, `memunmap_pages`, page-table slab caches such as `pgtable-*`, or stack traces involving sysfs driver unbind. Also review for suspicious local users or services repeatedly invoking persistent memory commands, writing to `/sys/bus/*/drivers/*/unbind`, or causing kernel oops/panic events. Absence of these artifacts does not prove non-exploitation, because a successful privilege-escalation attempt may avoid a visible crash, and systems without persistent kernel logging may lose evidence after reboot.

• BUG: KASAN: double-free in kasan_remove_zero_shadow
• kasan_report_invalid_free
• kasan_remove_zero_shadow
• kasan_free_pxd
• memunmap_pages
• Free of addr
• belongs to the cache pgtable-
• pgtable-2^9
• Disabling lock debugging due to kernel taint
• device_unbind_cleanup
• device_release_driver_internal
• unbind_store
• drv_attr_store
• sysfs_kf_write
• kernfs_fop_write_iter
• Comm: ndctl
• /sys/bus/*/drivers/*/unbind
• ndctl

What your security team should do

• Inventory Linux systems running affected kernel lines, prioritizing PowerPC, large-page configurations, KASAN-enabled kernels, persistent memory systems, memory hotplug systems, and shared multi-user hosts.
• Apply vendor kernel updates that include the fix, then reboot and verify the active running kernel version.
• Prioritize patching for systems where untrusted users, containers, build jobs, HPC users, or application workloads can obtain local execution.
• Restrict access to persistent memory administration, device unbind interfaces, memory hotplug operations, and sysfs driver-management paths to trusted administrators only.
• Monitor kernel logs for KASAN double-free reports, invalid frees, slab allocator warnings, oopses, or panics involving kasan_remove_zero_shadow(), kasan_free_pxd(), memunmap_pages(), ndctl, or driver unbind operations.
• Treat unexplained kernel crashes on affected systems as potentially security-relevant and preserve kernel logs, crash dumps, and audit records before rebooting or reimaging.
• Because EPSS is low, KEV is false, and no exploit maturity is reported, schedule remediation according to kernel local privilege escalation policy, but do not defer on shared or high-impact infrastructure.