CVE-2026-68173ublk: wait on ublk_dev_ready() instead of ub->completion
- 7.1HighCVSS base score
- 0.16%Exploitation in 30 daysEPSS · top 95% of all CVEs
- NoKnown exploitednot in CISA's KEV catalog
- NonePublic exploitsnone known yet
Description
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.
Timeline
ID reserved
By Linux
- 11 days later
· 11 days later
Published
- 7 days later
· 7 days later
Record updated
Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.
Scores
| Scored by | CVSS | Score | Vector |
|---|---|---|---|
| LinuxCNA (assigner) | 3.1 | High7.1 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H |
| NVDNVD · Received | 3.1 | High7.1 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H |
- EPSS (exploitation in 30 days)
- 0.16% · top 95% of all CVEs (13 Nov 2026)
The list uses the assigner's score when there is one, then CISA's, then NVD's: High 7.1.
Affected products
- affected 728cbac5fe219d3b8a21a0688a08f2b7f8aeda2b – < 7dd26adf7e7d482af524e3a0cca4a81ef7c159d0
- affected 728cbac5fe219d3b8a21a0688a08f2b7f8aeda2b – < 8f188dd11a1c2ad94caeaee36ef68bb8221d4a12
- affected 728cbac5fe219d3b8a21a0688a08f2b7f8aeda2b – < 432a9b2780c0a01caf547bd1fc2fcf28aeb8d173
- affected 42ea64e01c96e594fb4f80c54dfe4f934d008a6e
- affected 6.14.6 – < 6.15
- affected 6.15
- unaffected < 6.15
- unaffected 6.18.42 – ≤ 6.18.*
- unaffected 7.1.6 – ≤ 7.1.*
- unaffected 7.2 – ≤ *
References
Sources
The same CVE in the primary databases and aggregators, to check against.
- CVE.org record (opens in a new tab)
- CVE List JSON (GitHub) (opens in a new tab)
- NVD (opens in a new tab)
- FIRST EPSS (opens in a new tab)
- EUVD EUVD-2026-55274 (opens in a new tab)
- OSV.dev (opens in a new tab)
- GitHub Advisories (opens in a new tab)
- CIRCL Vulnerability-Lookup (opens in a new tab)
Badge for a README or a ticket
[](https://cveledger.app/cve/CVE-2026-68173)Record last updated .