CVE-2026-43292

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel vmalloc cleanup path. When KASAN shadow pages are released during vmalloc purge processing and CONFIG_PAGE_OWNER is enabled, freeing many pages can repeatedly perform stack unwinding under RCU read-side critical sections without yielding the CPU. A sufficiently large vmalloc purge workload can cause long CPU monopolization, RCU stalls, scheduler starvation, and in severe cases memory pressure or out-of-memory behavior. The upstream fix adds periodic rescheduling points during kasan_release_vmalloc_node() processing so RCU grace periods and other tasks can make progress.

Why it matters to the business

Successful exploitation can make affected Linux systems slow, unstable, or temporarily unavailable. Because exploitation requires local privileges and specific kernel/debug configuration exposure, the risk is generally highest on development, testing, debugging, CI, kernel fuzzing, and specialized observability systems rather than standard production builds. If affected configurations are present on critical hosts, the operational impact can include service interruption, failed jobs, node eviction, watchdog resets, or emergency reboots.

How an attack unfolds

An attacker who already has local code execution on an affected Linux system can create conditions that generate a large number of vmalloc allocations and frees. When the kernel later purges the accumulated vmap areas, the cleanup path releases KASAN shadow memory for many entries. With page-owner tracking enabled, each page free can trigger stack collection and RCU activity. Because the vulnerable loop does not reschedule often enough, the worker processing the purge list can run for an extended period without yielding, causing RCU stall warnings and starving other kernel work. The attacker’s practical goal is availability impact: degrading the host, triggering watchdog behavior, or contributing to out-of-memory conditions rather than stealing data or escalating privileges.

How to fix it

Upgrade to a Linux kernel build that includes the upstream vmalloc/KASAN fix adding periodic cond_resched() behavior in kasan_release_vmalloc_node(). Because no exact fixed package versions were provided, use the latest stable kernel or the latest distribution/vendor kernel security update that references this issue. Where immediate patching is not possible, reduce exposure by avoiding KASAN-enabled kernels on shared or production systems, disabling CONFIG_PAGE_OWNER/page-owner tracking unless required for debugging, limiting untrusted local shell or container workloads on affected debug kernels, and using workload isolation or scheduling controls to prevent untrusted users from generating excessive vmalloc churn. Reboot into the patched or mitigated kernel after updating.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release or custom build containing the vmalloc/KASAN rescheduling fix. Validate kernel configuration with /boot/config-$(uname -r), /proc/config.gz, or vendor build metadata to determine whether CONFIG_KASAN and CONFIG_PAGE_OWNER are enabled. Review boot parameters for page_owner=on or other debug options that increase exposure. On test systems only, reproduce a representative vmalloc stress workload before and after patching and confirm that prolonged RCU stall messages no longer occur during vmalloc purge processing. Also verify that production systems are not unintentionally running sanitizer/debug kernels.

Typical attack path

1. Gain local ability to run code or workloads on an affected Linux host.
2. Confirm or assume the host is running a kernel built with the relevant debugging/sanitizer options, especially KASAN and page-owner tracking.
3. Generate heavy vmalloc allocation and free activity to populate large vmap purge lists.
4. Trigger or wait for vmalloc purge processing to release KASAN shadow pages.
5. Cause the vulnerable cleanup loop to monopolize CPU without sufficient rescheduling.
6. Induce RCU stall warnings, scheduler starvation, memory pressure, service degradation, or system instability.

How to detect it

Look for evidence of kernel availability degradation rather than data theft. Review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, and crash dump records for RCU stall warnings, hung kworkers, stack traces involving kasan_release_vmalloc_node(), purge_vmap_node(), vmalloc cleanup, page_owner, or save_stack(). Correlate these events with local user activity, container workloads, CI jobs, fuzzing jobs, or processes that performed high allocation/free churn shortly before the stall. Check for repeated systemd watchdog resets, kernel soft lockups, OOM killer activity, node not-ready events, or unexpected reboots near the same timestamps. Because this issue is a local DoS and no public exploit maturity is indicated, detection should focus on anomalous local workload behavior followed by the characteristic kernel log messages rather than network indicators.

• rcu: INFO: rcu_preempt detected stalls on CPUs/tasks
• Tasks blocked on level-0 rcu_node
• kasan_release_vmalloc_node
• purge_vmap_node
• mm/vmalloc.c
• save_stack
• CONFIG_PAGE_OWNER
• page_owner=on
• BUG: soft lockup
• watchdog: BUG: soft lockup
• INFO: task kworker
• Out of memory: Killed process

What your security team should do

• Prioritize patching Linux systems that run KASAN, page-owner tracking, debug kernels, kernel fuzzing workloads, CI runners, or untrusted local workloads.
• Inventory hosts for CONFIG_KASAN, CONFIG_PAGE_OWNER, and page_owner=on to identify systems with meaningful exposure.
• Restrict local code execution on affected systems until patched, especially shared development servers and container hosts using debug kernels.
• Apply the latest vendor kernel update or rebuild custom kernels with the upstream fix, then reboot into the fixed kernel.
• Disable page-owner tracking and avoid KASAN-enabled kernels on production systems unless there is a specific operational need.
• Monitor kernel logs for RCU stall and vmalloc/KASAN stack traces as signs of attempted or accidental triggering.
• Document remaining exceptions and compensate with local access controls, resource limits, and rapid reboot/recovery procedures.