Skip to content
Fencer Vulns
high 7.1

CVE-2026-68173 json

ublk: wait on ublk_dev_ready() instead of ub->completion

published 2026-08-10 2 mo ago modified 2026-08-17 2 mo ago also EUVD-2026-55274

cvss
7.1
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 5%
public exploits
0
none known

Summary

In the Linux kernel, the following vulnerability has been resolved:

ublk: wait on ublk_dev_ready() instead of ub->completion

ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery.

ub->completion is an edge-triggered latch used as a proxy for the level condition "every queue has fetched all I/O commands", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed.

Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.

Patch / fix

  • Linux Linux 6.15, 6.18.42, 7.1.6, 7.2
  • linux Debian 14 7.1.6-1

debian advisories DEBIAN-CVE-2026-68173

  • linux Ubuntu 26.04 LTS 7.0.0-38.38
  • linux-aws Ubuntu 26.04 LTS 7.0.0-1014.14
  • linux-gcp Ubuntu 26.04 LTS 7.0.0-1014.14
  • linux-gke Ubuntu 26.04 LTS 7.0.0-1008.9
  • linux-ibm Ubuntu 26.04 LTS 7.0.0-1015.15
  • linux-azure Ubuntu 26.04 LTS 7.0.0-1017.17
  • linux-riscv Ubuntu 26.04 LTS 7.0.0-38.38.1
  • linux-oracle Ubuntu 26.04 LTS 7.0.0-1013.13

ubuntu advisories UBUNTU-CVE-2026-68173

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-68173 updated cvss 5.5

kernel: ublk: wait on ublk_dev_ready() instead of ub->completion

  • Red Hat Enterprise Linux 10 kernel
    affected: workaround, no fix available “Fix deferred”
  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

Exploit prediction

0.16% chance of exploitation in the next 30 days, higher than 5% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
CNA 3.1 7.1 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.