Skip to content
Heist/ feed
Back to feed
HighFix available

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

Type: advisorySources: OSV

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 retur

Products
Kernel
Affected versions
Not specified
Fixed versions
6.18.42, 7.1.6
CVEs
CVE-2026-68173
Confirmed fixed CVEs
Not specified
Updated in this feed
28 Oct 2026, 08:57 UTC · Revision 1

Source evidence

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

core-osv · Original source

Published 10 Aug 2026, 11:59 UTC

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 retur

osv:CVE-2026-68173

Kernel

Fixed versions: 6.18.42, 7.1.6

Complete source record
{
  "id": "d5213f172e5b8ce7389de29c3ceb3f42ebfd2191b436077e297b2088e3dbeffe",
  "url": "https://osv.dev/vulnerability/CVE-2026-68173",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "ublk: wait on ublk_dev_ready() instead of ub->completion",
    "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 retur",
    "evidence": "osv:CVE-2026-68173",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.18.42",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "7.1.6",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "high",
    "structured": {
      "id": "CVE-2026-68173",
      "aliases": [
        "CVE-2026-68173"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "728cbac5fe219d3b8a21a0688a08f2b7f8aeda2b"
                },
                {
                  "fixed": "7dd26adf7e7d482af524e3a0cca4a81ef7c159d0"
                },
                {
                  "fixed": "8f188dd11a1c2ad94caeaee36ef68bb8221d4a12"
                },
                {
                  "fixed": "432a9b2780c0a01caf547bd1fc2fcf28aeb8d173"
                }
              ]
            },
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "6.14.6"
                },
                {
                  "fixed": "6.15"
                }
              ]
            },
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "42ea64e01c96e594fb4f80c54dfe4f934d008a6e"
                }
              ]
            }
          ],
          "versions": [
            "v6.14.11",
            "v6.14.10",
            "v6.14.9",
            "v6.14.8",
            "v6.14.7",
            "v6.14.6"
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-68173.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.15.0"
                },
                {
                  "fixed": "6.18.42"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.19.0"
                },
                {
                  "fixed": "7.1.6"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-68173.json"
          }
        }
      ],
      "modified": "2026-10-08T02:51:36.293094456Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/432a9b2780c0a01caf547bd1fc2fcf28aeb8d173",
        "https://git.kernel.org/stable/c/7dd26adf7e7d482af524e3a0cca4a81ef7c159d0",
        "https://git.kernel.org/stable/c/8f188dd11a1c2ad94caeaee36ef68bb8221d4a12",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/68xxx/CVE-2026-68173.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-68173",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/68xxx/CVE-2026-68173.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-68173",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 98323,
  "published_at": "2026-08-10T11:59:42.889+00:00"
}