Cloudanix VulnDB

CVE-2025-68372

None

CVSS

—

EPSS

0.2%

Published

Dec 24, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's network storage driver can cause crashes or security issues when certain configuration commands are used together, fixed by updating to a newer kernel version.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in Linux kernel NBD recv_work due to premature nbd_config_put during NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE interleaving, allowing config and recv_threads to be freed while worker threads still reference them.

Why it matters to the business

Kernel instability or potential code execution on Linux systems using network block devices for storage, with low urgency given absence from known exploitation lists and stable EPSS trend over 306 days since publication.

How an attack unfolds

An attacker with local access triggers NBD connections, opens, CLEAR_SOCK ioctls, reconfigures, and closes in specific sequences to race the reference count to zero, causing UAF when recv_work later decrements recv_threads.

How to fix it

Apply the upstream fix by updating the Linux kernel to commit 198aa230a6f8c1f6af7ed26b29180749c3e79e4d or later stable releases containing the change that moves nbd_config_put to the end of recv_work; for trufflehog-fips update to 3.88.17-r0.

How to confirm the fix worked

Verify kernel source contains the corrected recv_work ordering after the referenced commit, confirm NBD reference counting paths no longer allow zero-ref during active workers, and test with NBD_CLEAR_SOCK plus reconfigure workloads.

Typical attack path

  1. Establish NBD connection via netlink increasing conf_ref
  2. Open NBD device to further increment references
  3. Issue NBD_CLEAR_SOCK ioctl to drop references
  4. Trigger NBD_CMD_RECONFIGURE or close device to interleave with recv_work
  5. Allow recv_work to execute config_put and atomic_dec after final reference drop causing UAF

How to detect it

Inspect kernel logs and crash dumps for NBD recv_work UAF signatures, trace NBD netlink ioctl sequences involving CLEAR_SOCK and reconfigure, and correlate with device open/close events around worker thread decrements.

What your security team should do

  • Prioritize kernel updates on systems exposing NBD devices
  • Audit NBD usage in virtualized or container storage stacks given downstream Linux prevalence
  • Monitor for NBD-related kernel oops or crashes in system logs
  • Apply the fix before any planned rmmod or module reload scenarios involving NBD

The record

In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying the waiter") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 5.10.0 5.10.248
Linux Kernel 5.10.0 6.12.63
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-azure 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.26.1.160000.2.7
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.26.1
openSUSE:Tumbleweed kernel-source 0 6.18.5-1.1
openSUSE:Tumbleweed kernel-source-longterm 0 6.18.16-1.1

Related vulnerabilities