CVE-2026-45949

What it actually does

This is a Linux kernel race condition in the hardware random number generator (hwrng) core. Concurrent or rapidly repeated hwrng register/unregister paths can cause the kernel to stop or reference the same hwrng fill thread after its task structure has already been freed, resulting in a use-after-free. The known impact is availability loss: a local, low-privileged attacker who can trigger the affected hwrng lifecycle paths may be able to crash the kernel or destabilize the host. The CVSS vector indicates local access, high attack complexity, low privileges required, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can cause affected Linux systems to crash or become unstable, interrupting workloads, virtual machines, appliances, or services that depend on the host. Because this is a kernel-level flaw, recovery may require rebooting affected systems and could cause service downtime. The public exploitation signal is currently low, with no CISA KEV listing, no known ransomware association, and a very low EPSS score, so remediation should be handled through normal kernel patch cycles unless the environment exposes frequent device hotplug, virtual RNG, kernel module, or hwrng driver churn.

How an attack unfolds

An attacker first obtains local access to an affected Linux system with sufficient privileges or available interfaces to influence hwrng device, driver, module, or virtual RNG lifecycle activity. The attacker then repeatedly triggers timing-sensitive hwrng registration and unregistration events, attempting to hit the race window where the global hwrng fill thread pointer is stale or where cleanup paths call kthread_stop() more than once for the same task. If the race is won, the kernel may attempt to increment or operate on a freed task reference, producing a use-after-free condition. In the documented failure mode, this results in kernel warnings and can lead to a crash or denial of service rather than data theft or privilege escalation. Exploitation is expected to be unreliable because it requires local access and precise timing.

How to fix it

Update the Linux kernel to a vendor release that includes the hwrng core race-condition fix using RCU and serialized hwrng_fill lifecycle handling. Because no exact fixed package versions were provided, use the security advisory or changelog from the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform vendor and install the first kernel build that references this hwrng race/use-after-free fix. Reboot systems after installing the fixed kernel so the patched kernel is actually running. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting kernel module loading and device-management privileges, avoiding unnecessary hwrng/virtio-rng hotplug operations, and disabling unused hwrng-related drivers only if operationally safe and supported by the vendor.

How to confirm the fix worked

Confirm exposure by checking the running kernel version with uname -r and comparing it to the vendor advisory for this issue, not just the installed package inventory. Confirm remediation by verifying that the running kernel is the patched vendor build after reboot. Review distribution changelogs or kernel source patches for changes in the hwrng core involving rng_mutex serialization, RCU use for current_rng, delayed cleanup via work_struct, and corrected kthread_stop() handling. For runtime validation, monitor kernel logs during hwrng driver load/unload or virtio-rng attach/detach testing in a non-production environment and confirm there are no use-after-free, refcount, kthread_stop(), hwrng_unregister(), or virtrng_remove warnings.

Typical attack path

1. Gain local access to a Linux system running an affected kernel.
2. Identify whether hwrng, virtio-rng, or related hardware RNG drivers are present and can be triggered.
3. Repeatedly cause hwrng register/unregister activity, such as driver removal/reload, device hotplug, or virtual RNG attach/detach where permitted.
4. Attempt to race hwrng_fill thread startup, shutdown, and cleanup paths.
5. Trigger a use-after-free in kthread_stop() or related hwrng cleanup logic.
6. Cause a kernel warning, panic, hang, or other availability-impacting failure.

How to detect it

To determine whether this was already triggered, review kernel logs and crash artifacts for hwrng-related use-after-free symptoms. Primary sources include journald kernel messages, /var/log/kern.log, /var/log/messages, dmesg output, pstore/ramoops records, kdump/vmcore data, hypervisor console logs, and EDR telemetry that captures kernel panics or module operations. Look for refcount warnings, use-after-free messages, kernel call traces, or panics containing kthread_stop(), hwrng_unregister(), hwrng_fillfn(), drop_current_rng(), put_rng(), or virtrng_remove(). Correlate these events with local user activity, sudo/audit logs, module load/unload events, device hotplug events, virtualization management activity, or virtio-rng attach/detach operations shortly before the crash. Because the vulnerability is a race condition and may only leave a crash trace, absence of explicit indicators does not fully rule out attempted exploitation. There are no known public threat actors or ransomware campaigns associated with this issue based on the provided intelligence.

• refcount_t: addition on 0; use-after-free
• refcount_warn_saturate
• kthread_stop+0x181/0x360
• hwrng_unregister+0x288/0x380
• virtrng_remove+0xe3/0x200
• hwrng_unregister
• hwrng_fillfn
• drop_current_rng
• put_rng
• kthread_stop
• use-after-free
• WARNING: .* at lib/refcount.c

What your security team should do

• Inventory Linux systems and prioritize those using virtualization, virtio-rng, hardware RNG devices, custom kernels, kernel module churn, or automated device hotplug.
• Track vendor advisories and upgrade to the first kernel release that contains the hwrng core fix; reboot after installation.
• Prioritize patching internet-facing infrastructure hosts, virtualization platforms, shared compute nodes, and systems where untrusted users have local access, even though exploitation is local and high-complexity.
• Restrict local access and administrative capabilities that allow loading, unloading, or manipulating hwrng-related drivers and devices.
• Add monitoring for kernel log indicators associated with this failure mode, especially refcount use-after-free warnings involving kthread_stop(), hwrng_unregister(), or virtrng_remove.
• If kernel crashes have occurred, preserve kernel logs, crash dumps, pstore records, and audit logs before reboot rotation overwrites evidence.
• Do not treat this as an active mass-exploitation emergency based on current intelligence: it is not in CISA KEV, has no known ransomware association, and has very low EPSS, but it should still be remediated through standard kernel maintenance.