KernelScan.io

HIGH

hwrng FillThread UAF

CVE-2026-45949

CVSS 7.8 / 10.0 KernelScan AI

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

01

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.

02

Engine v0.2.0

Risk summary

Local attackers with low privileges can trigger use-after-free conditions in the hardware random number generator subsystem by racing hwrng_register() and hwrng_unregister() calls. This can lead to kernel crashes or potential privilege escalation through memory corruption.

Affecteddrivers/char/hw_random/core.c (hwrng subsystem)

Vulnerability analysis

The root cause is a race condition in hwrng thread management where hwrng_fill pointer is accessed outside rng_mutex protection, allowing concurrent hwrng_unregister() calls to invoke kthread_stop() on the same freed task_struct. The vulnerability occurs when hwrng_unregister() is called immediately after hwrng_register(), leaving hwrng_fill pointing to a freed thread that subsequent operations attempt to stop again. The fix implements RCU protection for current_rng access, moves hwrng_fill under mutex protection, and uses work_struct for delayed cleanup to prevent the use-after-free condition. Attack surface is local-only, requiring access to hwrng device registration/unregistration through sysfs or module loading/unloading.

03

BranchFixed inPatch commit
6.126.12.75d5b7730f0699
6.186.18.14dcf416eb88ea
6.196.19.4ad38f2cdfef9
mainline7.0cc2f39d6ac48