CVE-2026-45949
Analyzed Analyzed - Analysis Complete
Race Condition in Linux Kernel hwrng Core

Publication date: 2026-05-27

Last updated on: 2026-06-16

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: hwrng: core - use RCU and work_struct to fix race condition Currently, hwrng_fill is not cleared until the hwrng_fillfn() thread exits. Since hwrng_unregister() reads hwrng_fill outside the rng_mutex lock, a concurrent hwrng_unregister() may call kthread_stop() again on the same task. Additionally, if hwrng_unregister() is called immediately after hwrng_register(), the stopped thread may have never been executed. Thus, hwrng_fill remains dirty even after hwrng_unregister() returns. In this case, subsequent calls to hwrng_register() will fail to start new threads, and hwrng_unregister() will call kthread_stop() on the same freed task. In both cases, a use-after-free occurs: refcount_t: addition on 0; use-after-free. WARNING: ... at lib/refcount.c:25 refcount_warn_saturate+0xec/0x1c0 Call Trace: kthread_stop+0x181/0x360 hwrng_unregister+0x288/0x380 virtrng_remove+0xe3/0x200 This patch fixes the race by protecting the global hwrng_fill pointer inside the rng_mutex lock, so that hwrng_fillfn() thread is stopped only once, and calls to kthread_run() and kthread_stop() are serialized with the lock held. To avoid deadlock in hwrng_fillfn() while being stopped with the lock held, we convert current_rng to RCU, so that get_current_rng() can read current_rng without holding the lock. To remove the lock from put_rng(), we also delay the actual cleanup into a work_struct. Since get_current_rng() no longer returns ERR_PTR values, the IS_ERR() checks are removed from its callers. With hwrng_fill protected by the rng_mutex lock, hwrng_fillfn() can no longer clear hwrng_fill itself. Therefore, if hwrng_fillfn() returns directly after current_rng is dropped, kthread_stop() would be called on a freed task_struct later. To fix this, hwrng_fillfn() calls schedule() now to keep the task alive until being stopped. The kthread_stop() call is also moved from hwrng_unregister() to drop_current_rng(), ensuring kthread_stop() is called on all possible paths where current_rng becomes NULL, so that the thread would not wait forever.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-27
Last Modified
2026-06-16
Generated
2026-06-16
AI Q&A
2026-05-28
EPSS Evaluated
2026-06-15
NVD
CVE-2026-45949
EUVD
EUVD-2026-32233
Affected Vendors & Products
Showing 3 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 6.13 (inc) to 6.18.14 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.4 (exc)
linux linux_kernel From 3.17 (inc) to 6.12.75 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Mitigation Strategies

The vulnerability is resolved by a patch that fixes race conditions in the Linux kernel's hwrng core by protecting the global hwrng_fill pointer with the rng_mutex lock and properly managing thread stopping and cleanup.

Immediate mitigation steps include updating the Linux kernel to a version that includes this patch to ensure the race condition and use-after-free issues are fixed.

Executive Summary

This vulnerability exists in the Linux kernel's hardware random number generator (hwrng) core. It involves a race condition caused by improper synchronization when starting and stopping kernel threads related to hwrng. Specifically, the global pointer hwrng_fill is accessed outside of a mutex lock, leading to potential use-after-free errors when threads are stopped or restarted concurrently.

The issue arises because hwrng_fill is not cleared until the thread function exits, and hwrng_unregister() can call kthread_stop() multiple times on the same task, or on a task that was never started. This causes use-after-free bugs, which can lead to kernel crashes or undefined behavior.

The fix involves protecting the hwrng_fill pointer with a mutex lock to serialize thread start and stop operations, converting some data structures to use Read-Copy-Update (RCU) mechanisms to avoid deadlocks, and ensuring threads are properly kept alive until stopped.

Impact Analysis

This vulnerability can lead to use-after-free conditions in the Linux kernel, which may cause system instability, crashes, or potential kernel memory corruption.

Such kernel-level issues can affect the reliability and security of systems running vulnerable Linux kernels, potentially leading to denial of service or enabling attackers to exploit the kernel for privilege escalation or other malicious activities.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-45949. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart