CVE-2026-53162

What it actually does

The flaw is a Linux kernel race/reentrancy issue in the memory cgroup charging path. During memcg stock refill/drain operations, the kernel could call get_random_u32_below() from NMI context. That random-number helper is not NMI-safe because it uses per-CPU batched entropy state protected by local locking that can be interrupted and re-entered by an NMI. If an NMI occurs while the CPU is updating the random subsystem’s per-CPU ChaCha batch state and memcg charge draining re-enters the random subsystem, the per-CPU random state can be corrupted. The kernel fix removes the random victim selection and replaces it with a local round-robin counter guarded by the existing memcg per-CPU stock lock.

Why it matters to the business

Successful triggering is most likely to cause kernel instability, crashes, or unpredictable behavior on affected Linux systems, resulting in service disruption for workloads using memory cgroups such as containers, systemd-managed services, and multi-tenant compute nodes. There is no current CISA KEV listing, no known ransomware association, no public exploit maturity reported, and the EPSS score is very low, so urgency is lower than for actively exploited remote vulnerabilities; however, kernel flaws should still be remediated through normal patch cycles because they can affect platform reliability at scale.

How an attack unfolds

An attacker would generally need the ability to run code or influence workloads on an affected Linux host. They would attempt to create heavy memory-cgroup charge and drain activity while also increasing the likelihood of NMI-context execution, for example through performance-monitoring, watchdog, profiling, or hardware-interrupt-heavy conditions available to the workload. If an NMI interrupts the CPU while the random subsystem is updating its per-CPU batched entropy state, and memcg charge draining re-enters get_random_u32_below(), the random state can be corrupted. The practical outcome is expected to be denial of service or kernel instability rather than a straightforward remote compromise path.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix replacing random victim selection in memcg refill_stock with a per-CPU round-robin counter. Because no affected product list or exact fixed package versions were provided, use the relevant Linux distribution, appliance, cloud image, container host, or kernel vendor advisory to identify the corrected kernel package for each platform. Prioritize patching container hosts, Kubernetes nodes, virtualization hosts, high-density multi-tenant systems, and systems that make heavy use of memory cgroups. If immediate patching is not possible, reduce exposure by limiting untrusted local code execution, restricting access to performance-monitoring interfaces where feasible, disabling or tightly controlling unprivileged perf_event usage, and scheduling maintenance windows for kernel upgrades and reboots.

How to confirm the fix worked

Confirm that running systems have been rebooted into a kernel version that includes the memcg refill_stock round-robin fix. Validate against vendor advisories or kernel changelogs for the patch text referencing 'memcg: use round-robin victim selection in refill_stock'. Check the active kernel with standard platform tooling such as uname -a and package-manager queries, not only the installed package list, because kernel updates require a reboot to take effect. Where source or symbol verification is available, confirm that the vulnerable path no longer calls get_random_u32_below() for memcg refill victim selection and instead uses the per-CPU round-robin counter in memcg_stock_pcp. Review kernel logs after remediation for absence of recurring NMI, random subsystem, memcg, oops, panic, or lockup messages under representative workload stress.

Typical attack path

1. Gain the ability to execute code or run a workload on an affected Linux system.
2. Place the workload in an environment that uses memory cgroups, such as containers, service slices, or resource-controlled processes.
3. Generate high memory allocation, charging, reclaim, and cgroup accounting churn to exercise memcg stock refill and drain paths.
4. Increase the chance of NMI-context execution through available system activity such as profiling, performance events, watchdog activity, or interrupt-heavy workload behavior.
5. Race an NMI against the kernel random subsystem’s per-CPU state update so that memcg charge draining re-enters a non-NMI-safe random helper.
6. Trigger random subsystem state corruption, potentially resulting in kernel warnings, oopses, panic, lockups, or service disruption.

How to detect it

There are no known public exploitation indicators, no KEV listing, and no reported mature exploit for this issue. Detection should focus on signs that the vulnerable race may have been triggered: kernel oopses or panics involving memory cgroups, refill_stock, get_random_u32_below, random subsystem per-CPU state, NMI context, or unexplained host lockups during memory-cgroup-heavy workloads. Review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, hypervisor reset records, node health events, and container-orchestrator node-not-ready events. Correlate suspected events with local workload activity, high memory allocation/reclaim rates, container churn, profiling/performance-event use, watchdog/NMI events, and sudden host reboots. Treat these artifacts as weak behavioral indicators rather than proof of malicious exploitation, because the same symptoms can arise from non-malicious kernel bugs or hardware faults.

• refill_stock
• get_random_u32_below
• batched_entropy_u32
• memcg_stock_pcp
• memcg: use round-robin victim selection in refill_stock
• NMI
• Oops:
• kernel panic
• BUG: unable to handle kernel
• general protection fault
• watchdog: BUG: soft lockup
• watchdog: BUG: hard LOCKUP
• Call Trace:
• mem_cgroup
• Memory cgroup

What your security team should do

• Inventory Linux systems that run memory-cgroup-heavy workloads, including container hosts, orchestration nodes, CI runners, virtualization hosts, and multi-tenant compute platforms.
• Map each platform to its vendor kernel advisory and identify the fixed kernel package or image that contains the memcg refill_stock round-robin change.
• Patch and reboot affected systems through the normal kernel maintenance process, prioritizing shared infrastructure and systems that allow untrusted or semi-trusted workload execution.
• Until patched, restrict local code execution and review controls around unprivileged performance events, profiling interfaces, and container escape-prevention hardening.
• Monitor kernel logs for unexplained oopses, panics, NMI-related warnings, random subsystem stack traces, memcg stack traces, and host lockups.
• Because the vulnerability is not currently in KEV, has no reported ransomware use, and has very low EPSS, treat it as reliability and defense-in-depth work unless internal exposure includes untrusted local workloads at scale.