A newly assigned CVE, CVE-2025-68372, documents a use-after-free (UAF) race in the Linux kernel’s Network Block Device (NBD) driver that can result in worker-thread access to freed configuration memory. The fix is small but important: the NBD code now defers the final configuration put — calling nbd_config_put — until after the worker’s recv_work has finished, ensuring the configuration reference remains valid for the lifetime of the worker thread. Public disclosures, a kernel patch, and multiple vulnerability trackers confirm the flaw and its patch.
Background
What is NBD and why it matters
The Network Block Device (NBD) is a kernel driver that exposes block devices backed by a remote server. It is commonly used for network-backed block storage, testing, and in some orchestration or virtualization setups where remote block backends are attached on demand. Because NBD plugs directly into block-device and kernel workqueue paths, bugs in its code can lead to crashes, resource leaks, or corruption visible at the kernel level.How reference counting and worker threads interplay
The kernel uses reference counting to ensure objects (such as an NBD configuration) are not freed while other code still uses them. NBD employs a worker function — recv_work — that runs on a workqueue thread and manipulates configuration and socket objects. The interaction between asynchronous operations (netlink/genetlink control messages), ioctl-driven operations, and workqueue handling creates subtle timing windows where the last reference to a configuration object can be dropped prematurely. The CVE centers on one such timing window that yields a use-after-free.The vulnerability in plain terms
The race and its short sequence
At a high level, the bug appears when a sequence of control operations interleave across threads so that two distinct recv_work instances and control operations decrement the same configuration reference in an unexpected order. The published diag explains two representative interleavings:- Interleaving A + B (connect, open, clear socket, reconfigure, close) leads to a path where recv_work B calls config_put which drops the last reference and then calls atomic_dec(&config->recv_threads), causing the worker to access freed memory.
- A simpler path with only NBD_CLEAR_SOCK can similarly lead to config_put being called twice with the second call occurring inside recv_work, dropping the final reference and producing a UAF.
The exact patch
The upstream patch (authored by Zheng Qixing) is minimal and surgical: in drivers/block/nbd.c, the call to nbd_config_put that previously ran before the wake-up of any waiter has been moved to after the wake_up(&config->recv_wq) and after the atomic decrement. The patch moves the config_put to the end of recv_work, which makes the reference last for the full lifetime of the worker thread. The change is one line: the position of the nbd_config_put call is adjusted so the configuration reference is not released while recv_work might still be executing. The patch was reported via syzbot (an automated kernel bug finding system) and submitted to the kernel mailing lists.Technical analysis
Why the original change that caused the bug existed
The prior commit (referenced in the disclosure) had deliberately moved nbd_config_put earlier — before waking up waiter threads — to prevent another race where nbd_start_device_ioctl could be woken while nbd->task_recv had not yet cleared. That earlier change avoided a race (and potential hung task) in one code path, but inadvertently introduced the use-after-free by moving the put before the workqueue lifetime ended. The newest patch rebalances correctness by moving the put back to the end of recv_work while relying on a flush_workqueue that is already used in nbd_start_device_ioctl. In short, the fix reorders operations to hold the configuration reference for the lifetime of the worker thread — a classic reference-counting solution for UAF races.Attack surface and prerequisites
- Locality: This is a local vulnerability; it requires interactions with the NBD driver (i.e., creating NBD connections and issuing control messages). Public trackers classify the attack vector as local.
- Privileges: The operation paths affected involve control messages and ioctl-like flows that typically require at least low-level privileges (for example, CAP_SYS_ADMIN) or local administrative ability to attach or reconfigure NBD devices. Distribution metadata marks the required privileges as low in some scorings — meaning a non-root user with specific capabilities or misconfigurations could potentially trigger the condition in some setups. Administrators should not assume no privilege is required.
- Impact: The bug is a UAF that can lead to kernel crashes (denial-of-service) or possibly memory corruption. Public advisories emphasize availability impact (DoS) rather than confidentiality or integrity. SUSE’s evaluation lists Availability as the main concern and assigns moderate severity/score reflecting that the primary real-world impact is service interruption.
Exploitation practicality
Turning a kernel UAF into reliable code execution is often nontrivial; the attacker needs precise timing and knowledge of allocator behavior. Given the local nature and the involvement of control plane operations, the more immediate and practical risk is denial-of-service: causing kernel crashes or hung workqueues. There are no widely circulated, confirmed public proofs-of-concept (PoCs) as of the CVE publication window — but the presence of an exploitable UAF at kernel level warrants a patching response because weaponizing such issues can sometimes be achieved by determined attackers or automated fuzzers. Public trackers have not yet assigned a high EPSS score.Affected kernel versions and where fixes appear
Upstream vulnerability trackers and OSV package data indicate specific ranges where the issue was introduced and the kernel branches where fixes were applied:- The vulnerability traces into multiple upstream stable series; the OSV entry lists Introduced tags for older series and lists fixes:
- Fixed in kernel versions: 6.12.63, 6.17.13, and 6.18.2 (and associated stable branch backports).
- The LKML patch shows the upstream commit that corrects the behavior in drivers/block/nbd.c; that patch is the fix now reflected in stable backports. Administrators should look for those fixed patch levels in their distribution kernel packages.
Severity, scoring, and real-world risk
- SUSE’s assessment marks the issue as moderate, with CVSS v3 base score 5.5 (availability-focused) and CVSS v4 base score 6.8. SUSE highlights the local attack vector and low required privileges, concluding the principal impact is on availability (DoS).
- Public trackers (NVD, OSV, CVE aggregation sites) emphasize the UAF nature and note the worker thread lifetime as the core fix mechanism. These sources place the defect in the “local crash/DoS” category rather than an immediately trivial privilege escalation or remote code execution vector.
Recommended mitigation and remediation steps
Administrators should prioritize patching where feasible. The recommended remediation steps are:- Confirm whether your systems run a vulnerable kernel:
- Check kernel version: uname -r
- Check whether the nbd module is present: modinfo nbd or lsmod | grep nbd
- Update kernels to patched versions:
- For upstream kernels, install a kernel that includes the fixes (for example, kernels at or beyond 6.12.63, 6.17.13, or 6.18.2 where applicable) or apply the upstream patch and rebuild.
- For distribution kernels, install the vendor-supplied security update once published and verified.
- If you cannot immediately patch, apply temporary mitigations:
- Unload the nbd module (if not required): sudo rmmod nbd
- Blacklist nbd to prevent automatic loading:
- Create /etc/modprobe.d/nbd-blacklist.conf with a line: blacklist nbd
- Restrict who can perform NBD control operations:
- Limit CAP_SYS_ADMIN capability where possible and restrict access to control interfaces (e.g., netlink/genetlink consumers).
- Monitor dmesg/syslog for nbd-related KASAN prints, kernel oops, or worker thread crashes which may indicate the bug has been triggered.
- Validate after patching:
- After installing the updated kernel package and rebooting, confirm the new kernel version and that no nbd-related OOPS/kasan reports are present in logs.
- Check kernel: uname -r
- Check loaded module: lsmod | grep nbd
- Show module info: modinfo nbd
- Unload module (immediate, may disrupt active NBD devices): sudo rmmod nbd
- Blacklist module: echo "blacklist nbd" | sudo tee /etc/modprobe.d/nbd-blacklist.conf
Patch hygiene and backport considerations
- The upstream patch is tiny (one-line reorder), but deploying it requires kernel rebuilds or vendor backports. Many distributions have stable kernel branches maintained separately; vendors may backport the logic to their major kernels rather than bumping the entire kernel series.
- When applying vendor-supplied updates, verify the change by auditing the nbd.c in the vendor kernel package or checking the vendor advisory to confirm the patch is included.
- Avoid ad-hoc copying of a patch into a running kernel tree in production without full testing. Race fixes can be subtle; regressions that reintroduce other races (e.g., deadlocks avoided by the earlier commit) are possible if changes are not applied exactly or if related fixes are missing. The upstream patch notes mention a dependency on an earlier e2daec4... fix addressing a hung task; ensure dependent commits are present when porting.
Timeline and attribution
- The bug was reported to the kernel community and tracked via syzbot (automated fuzzing), then patched upstream. The LKML patch submission and the subsequent CVE assignment and database entries were published in November–December 2025. The upstream patch author is credited on the LKML thread; public CVE entries and OSV/NVD listings followed as vendors and trackers processed the submission.
Practical takeaways for system administrators and kernel developers
- For system administrators:
- Treat this as a kernel-level availability risk for hosts that use NBD. Prioritize patching hosts that use NBD, especially if those hosts are multi-tenant or run automated workloads that could be abused to repeatedly trigger the condition.
- If NBD is not in use, consider blacklisting or unloading the module to reduce exposure until a vendor patch is installed.
- For kernel developers:
- The issue is an instructive example of how a fix for one race (preventing wakeups while a task flag is uncleared) can introduce another (shortening the lifetime of a config reference). When modifying reference-count ordering relative to wakeups and workqueue lifetimes, ensure the new ordering preserves object lifetime for all code paths, including worker threads and any flush_workqueue or flush operations called by wake-up waiters.
- Rely on systematic fuzzing and regression testing (KASAN, syzbot) to detect both UAF and deadlock regressions. Back-and-forth adjustments between reference puts and wake-ups are common sources of subtle concurrency bugs.
What remains uncertain and warnings about unverifiable claims
- There is no public evidence (at publication time) of an exploit in the wild that escalates this UAF to remote code execution. While such elevation is theoretically possible with targeted effort, the more immediate and verifiable impact is DoS/kernel crash. The absence of public PoC at the time of disclosure should not be taken to indicate low risk; kernel UAFs are prioritized because they are high-value targets for attackers and fuzzers alike.
- Distribution-specific timelines for patched kernels will vary. Administrators must consult their vendor advisories and not rely solely on upstream commit IDs — the presence of a fix upstream does not guarantee immediate vendor packages. SUSE, Debian, Ubuntu, Red Hat, and other vendors will announce patched package versions once backports are prepared and tested.
Conclusion
CVE-2025-68372 is a kernel-level use-after-free in the NBD driver arising from a subtle reference-count and wake-up ordering problem. The upstream fix is a simple but sound reordering that defers the configuration put until the worker thread completes, thereby guaranteeing the configuration remains valid for the worker's lifetime. The bug’s practical risk is mostly denial-of-service on systems that accept NBD control operations; however, any kernel UAF warrants rapid remediation. Administrators should prioritize installing vendor-supplied kernel updates that include the upstream fix or apply the mitigation of disabling/unloading the NBD module until a patched kernel is available. Prompt, tested patching and careful review of vendor advisories remain the correct operational response.Source: MSRC Security Update Guide - Microsoft Security Response Center
