{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-68173 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-68173 is a high-severity vulnerability in Linux, published on 10 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-68173 and fix it if it is affected.\n\nWhat it is: CVE-2026-68173 is a high-severity vulnerability in Linux, published on 10 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-68173 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-68173/ (Markdown: https://insights.sbomify.com/CVE-2026-68173/index.md)","id":"CVE-2026-68173","markdown":"https://insights.sbomify.com/CVE-2026-68173/index.md","name":"CVE-2026-68173","record":{"aliases":["BELL-CVE-2026-68173","DEBIAN-CVE-2026-68173","GHSA-mxh6-x24v-wwvm","UBUNTU-CVE-2026-68173"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel ublk","requires_auth":"low_privilege","summary":"A race condition in the Linux kernel ublk driver can cause requests to be stranded, leading to system hangs and denial of service during daemon recovery.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":7.1,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nublk: wait on ublk_dev_ready() instead of ub-\u003ecompletion\n\nub-\u003ecompletion is only re-armed by a successful START_USER_RECOVERY. If\nthe ublk server sends END_USER_RECOVERY without one - e.g. its START\nfailed with -EBUSY and the error was ignored - the wait is satisfied by\nthe stale completion of the previous recovery cycle, and the device is\nmarked LIVE and the requeue list kicked while the FETCH stream is still\nrunning and ubq-\u003ecanceling is still set. The kick redispatches a\npreviously requeued request, __ublk_queue_rq_common() sees -\u003ecanceling\nand parks it again via __ublk_abort_rq(), and after the last FETCH\nclears -\u003ecanceling nothing ever kicks the requeue list again: the\nrequest is stranded there while holding its tag. If it is the flush\nmachinery's flush_rq, every subsequent fsync piles up in uninterruptible\nsleep and teardown hangs on tag draining. This matches a report of a\nlost PREFLUSH with ext4 on top of ublk after daemon crash recovery.\n\nub-\u003ecompletion is an edge-triggered latch used as a proxy for the level\ncondition \"every queue has fetched all I/O commands\", which can regress\n(F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop\nit and wait on the real condition instead: the new helper\nublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via\nwait_var_event_interruptible(), woken from ublk_mark_io_ready(), then\nre-checks it under ub-\u003emutex, waiting again on regression, and returns\nwith the mutex held and readiness guaranteed.\n\nReadiness becomes true in the same ub-\u003emutex critical section that\nclears the last queue's -\u003ecanceling, so END_USER_RECOVERY marks the\ndevice LIVE and kicks the requeue list strictly after -\u003ecanceling\nclears. The wait stays interruptible, so a server whose daemon died can\nstill be signalled out. For ublk_ctrl_start_dev() this replaces the\nfail-fast -EINVAL on an F_BATCH ready-\u003eUNPREP regression with waiting\nuntil the device is ready again.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"ublk: wait on ublk_dev_ready() instead of ub-\u003ecompletion","id":"CVE-2026-68173","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"race_condition","year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"tracing: Fix union collision of module and refcnt for dynamic events","id":"CVE-2026-68174"},"packages":[],"prev":{"headline":"arm64: make huge_ptep_get handled unaligned addresses","id":"CVE-2026-68172"},"products":["Linux"],"published":"2026-08-10","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-08-17","vendors":["Linux"]},"summary":"A race condition in the Linux kernel ublk driver can cause requests to be stranded, leading to system hangs and denial of service during daemon recovery.","url":"https://insights.sbomify.com/CVE-2026-68173/"}