Cloudanix VulnDB

CVE-2025-68366

None

CVSS

—

EPSS

0.2%

Published

Dec 24, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing issue in the Linux kernel's network storage driver can cause crashes on systems that use remote disks, but it is not known to be actively exploited.

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

What it actually does

Use-after-free in NBD driver's reference counting during NBD_CMD_CONNECT and NBD_CLEAR_SOCK operations, where refcount_inc is performed on a config_refs value that has already reached zero after socket close.

Why it matters to the business

Kernel instability or crashes on systems using network block devices for storage, increasing operational risk in environments with high NBD usage; patch urgency remains low given absence from known exploited lists and stable EPSS.

How an attack unfolds

An attacker with local access issues concurrent NBD connect and clear socket operations, inserting timing delays to trigger the race that allows refcount_inc on a freed object, reproducing the use-after-free warning shown in the kernel log.

How to fix it

Apply the upstream fix from commit 330d688a5ca53857828081a3cf31b92ad1b0b3ed in the Linux kernel; for Chainguard packages update keda-fips, keda-admission-webhooks-fips, and keda-metrics-apiserver-fips to version 2.16.1-r4 or later.

How to confirm the fix worked

Verify the presence of the fixing commit in the running kernel source or confirm package versions match the listed fixed releases; test NBD connect/clear operations under load to ensure no refcount warnings occur.

Typical attack path

  1. Obtain local access on a system with NBD support enabled
  2. Issue NBD_CMD_CONNECT via nbd_genl_connect while holding config_refs
  3. Trigger NBD_CLEAR_SOCK followed by close to drop refs to zero
  4. Force a delay before refcount_inc to hit the freed reference
  5. Observe refcount warning and potential memory corruption

How to detect it

Search kernel logs and dmesg for the exact refcount warning string and the nbd_genl_connect stack trace; correlate with NBD device activity around the time of the warning.

  • refcount_t: addition on 0; use-after-free
  • nbd_genl_connect+0x16d0/0x1ab0
  • WARNING: CPU:.*PID:.*at lib/refcount.c:25 refcount_warn_saturate
  • before sleep
  • after sleep

What your security team should do

  • Prioritize kernel and affected package upgrades within normal maintenance windows
  • Monitor kernel logs for refcount warnings on NBD-enabled hosts
  • Limit NBD usage to trusted networks until patches are deployed
  • Review downstream dependents for any indirect exposure through container images

The record

In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk("before sleep\n"); + mdelay(5 * 1000); + printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 4.12.0 5.10.248
Linux Kernel 4.12.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