CVE-2026-46093

What it actually does

This is a local Linux kernel race condition in the vmalloc/vmap memory-management subsystem. The vulnerable code allows decay_va_pool_node() to run concurrently from the lazy vmap purge path and the kernel shrinker path without taking vmap_purge_lock on one path. That missing serialization can corrupt or desynchronize vmalloc area pool state, causing memory/resource leaks, instability, denial of service, and potentially unsafe kernel memory behavior. Because exploitation requires local code execution with low privileges, the main technical risk is post-access privilege escalation or kernel compromise rather than remote initial access.

Why it matters to the business

Systems running affected Linux kernels may be vulnerable to local attackers, compromised users, malicious workloads, or container escape attempts that try to abuse a kernel memory-management race to crash systems or gain elevated privileges. The operational impact can include service outages, host instability, compromise of sensitive data, and loss of trust in multi-user or multi-tenant Linux hosts. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has very low EPSS at this time, so remediation should be prioritized based on exposure to untrusted local users, shared compute, containers, and internet-facing services that could provide an attacker an initial foothold.

How an attack unfolds

An attacker first obtains the ability to run code locally on an affected Linux system, for example through a compromised account, exploited application, malicious job, or untrusted container workload. The attacker then creates kernel memory pressure and vmalloc/vmap allocation and free activity intended to cause the shrinker path and lazy vmap purge path to invoke decay_va_pool_node() at the same time. On vulnerable kernels, the shrinker path does not hold vmap_purge_lock, so the concurrent operations can race and leave vmalloc pool state inconsistent. A successful exploit could cause kernel instability or resource leakage and, depending on kernel configuration and surrounding memory state, may be leveraged as part of a local privilege-escalation chain. There is no indication from the supplied data of public weaponized exploit maturity or known in-the-wild exploitation.

How to fix it

Update affected Linux kernels to a vendor-supported build that includes the upstream fix adding vmap_purge_lock protection around decay_va_pool_node() in the shrinker path. Because no exact fixed package versions were provided, use distribution advisories and kernel changelogs to identify the first fixed kernel for each deployed platform. Prefer vendor kernel packages over manually backporting unless operating a custom kernel program. After updating, reboot into the fixed kernel and remove or restrict boot options for vulnerable kernels where operationally feasible. If immediate patching is not possible, reduce risk by limiting local shell access, restricting untrusted workloads, hardening container isolation, enforcing least privilege, and monitoring for kernel crashes or unusual memory pressure; these are mitigations only and do not remove the vulnerable code path.

How to confirm the fix worked

Confirm exposure by inventorying running kernel versions with commands such as uname -r and comparing them against the relevant Linux distribution security advisory or upstream stable kernel containing the vmalloc shrinker locking fix. Validate remediation by confirming the system has rebooted into the fixed kernel, not merely installed the package. For source-based or custom kernels, verify that the shrinker path in mm/vmalloc.c takes vmap_purge_lock before calling decay_va_pool_node() and releases it afterward. Perform regression checks for host stability, memory pressure behavior, and kernel logs after reboot. Vulnerability scanners should be configured to evaluate the running kernel version rather than only installed packages.

Typical attack path

1. Gain local code execution on a vulnerable Linux host as an unprivileged or low-privileged user.
2. Run code that repeatedly exercises vmalloc/vmap allocation and free behavior while creating memory pressure to trigger kernel shrinker activity.
3. Attempt to cause concurrent execution of the lazy vmap purge path and the shrinker path against the same vmalloc pool state.
4. Exploit the resulting race condition to induce kernel memory-management inconsistency, leaks, crash, or other unsafe behavior.
5. Use the resulting kernel instability or memory corruption primitive for denial of service or as part of a broader local privilege-escalation attempt.

How to detect it

Detection should focus on evidence of attempted local exploitation or resulting kernel instability, because this class of kernel race typically does not produce a unique network indicator. Review kernel logs from journald, dmesg, syslog, kdump, crash dump infrastructure, EDR telemetry, and audit logs for vmalloc/vmap-related warnings, kernel Oops or BUG events, soft lockups, memory allocation failures, and unexpected reboots. Correlate these events with local user sessions, newly executed binaries, container workloads, CI jobs, or services that generated unusual memory pressure shortly before the crash. Look for repeated crashes or instability on affected kernel versions, especially where untrusted users or workloads can execute code. Preserve vmcore/kdump artifacts where available for kernel stack analysis; relevant stack frames may include vmalloc, vmap purge, shrinker, decay_va_pool_node(), vmap_node_shrink_scan(), or __purge_vmap_area_lazy(). There are no known named threat actors or public exploit campaigns in the supplied data, so detections should be behavioral and crash-forensic rather than signature-only.

• decay_va_pool_node
• vmap_node_shrink_scan
• __purge_vmap_area_lazy
• vmap_purge_lock
• mm/vmalloc.c
• vmalloc
• vmap
• kernel BUG
• kernel Oops
• BUG: unable to handle kernel
• general protection fault
• soft lockup
• hung task
• Out of memory
• kdump
• vmcore

What your security team should do

• Prioritize patching Linux hosts that allow local user access, run untrusted code, provide shared build/CI infrastructure, host containers, or support multi-tenant workloads.
• Inventory running kernel versions across the fleet and map them to vendor advisories for this vmalloc/vmap shrinker race fix.
• Ensure patched systems are rebooted into the fixed kernel and that vulnerable fallback kernels are controlled or removed according to operational policy.
• Apply compensating controls until patching is complete: restrict local accounts, limit container privileges, disable unnecessary unprivileged namespaces where appropriate, and enforce least privilege.
• Monitor kernel logs and crash telemetry for vmalloc/vmap-related warnings, BUG/Oops events, memory allocation failures, and unexplained reboots.
• Treat suspicious kernel crashes following local process activity or memory pressure as potential exploitation attempts and preserve logs, crash dumps, and process/account context.
• Track vendor advisories for exact fixed package versions because no fixed versions were provided in the input data.