{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2025-68756 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2025-68756 is a vulnerability in Linux, published on 5 Jan 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-2025-68756 and fix it if it is affected.\n\nWhat it is: CVE-2025-68756 is a vulnerability in Linux, published on 5 Jan 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-2025-68756 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-2025-68756/ (Markdown: https://insights.sbomify.com/CVE-2025-68756/index.md)","id":"CVE-2025-68756","markdown":"https://insights.sbomify.com/CVE-2025-68756/index.md","name":"CVE-2025-68756","record":{"aliases":["AZL-73421","BELL-CVE-2025-68756","DEBIAN-CVE-2025-68756","GHSA-p2j4-mcw8-r88g","ROOT-OS-DEBIAN-13-CVE-2025-68756","ROOT-OS-UBUNTU-2404-CVE-2025-68756","UBUNTU-CVE-2025-68756"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel block layer","requires_auth":"none","summary":"A race condition in the Linux kernel block layer can cause a deadlock, leading to a denial of service.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nblock: Use RCU in blk_mq_[un]quiesce_tagset() instead of set-\u003etag_list_lock\n\nblk_mq_{add,del}_queue_tag_set() functions add and remove queues from\ntagset, the functions make sure that tagset and queues are marked as\nshared when two or more queues are attached to the same tagset.\nInitially a tagset starts as unshared and when the number of added\nqueues reaches two, blk_mq_add_queue_tag_set() marks it as shared along\nwith all the queues attached to it. When the number of attached queues\ndrops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and\nthe remaining queues as unshared.\n\nBoth functions need to freeze current queues in tagset before setting on\nunsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions\nhold set-\u003etag_list_lock mutex, which makes sense as we do not want\nqueues to be added or deleted in the process. This used to work fine\nuntil commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\")\nmade the nvme driver quiesce tagset instead of quiscing individual\nqueues. blk_mq_quiesce_tagset() does the job and quiesce the queues in\nset-\u003etag_list while holding set-\u003etag_list_lock also.\n\nThis results in deadlock between two threads with these stacktraces:\n\n  __schedule+0x47c/0xbb0\n  ? timerqueue_add+0x66/0xb0\n  schedule+0x1c/0xa0\n  schedule_preempt_disabled+0xa/0x10\n  __mutex_lock.constprop.0+0x271/0x600\n  blk_mq_quiesce_tagset+0x25/0xc0\n  nvme_dev_disable+0x9c/0x250\n  nvme_timeout+0x1fc/0x520\n  blk_mq_handle_expired+0x5c/0x90\n  bt_iter+0x7e/0x90\n  blk_mq_queue_tag_busy_iter+0x27e/0x550\n  ? __blk_mq_complete_request_remote+0x10/0x10\n  ? __blk_mq_complete_request_remote+0x10/0x10\n  ? __call_rcu_common.constprop.0+0x1c0/0x210\n  blk_mq_timeout_work+0x12d/0x170\n  process_one_work+0x12e/0x2d0\n  worker_thread+0x288/0x3a0\n  ? rescuer_thread+0x480/0x480\n  kthread+0xb8/0xe0\n  ? kthread_park+0x80/0x80\n  ret_from_fork+0x2d/0x50\n  ? kthread_park+0x80/0x80\n  ret_from_fork_asm+0x11/0x20\n\n  __schedule+0x47c/0xbb0\n  ? xas_find+0x161/0x1a0\n  schedule+0x1c/0xa0\n  blk_mq_freeze_queue_wait+0x3d/0x70\n  ? destroy_sched_domains_rcu+0x30/0x30\n  blk_mq_update_tag_set_shared+0x44/0x80\n  blk_mq_exit_queue+0x141/0x150\n  del_gendisk+0x25a/0x2d0\n  nvme_ns_remove+0xc9/0x170\n  nvme_remove_namespaces+0xc7/0x100\n  nvme_remove+0x62/0x150\n  pci_device_remove+0x23/0x60\n  device_release_driver_internal+0x159/0x200\n  unbind_store+0x99/0xa0\n  kernfs_fop_write_iter+0x112/0x1e0\n  vfs_write+0x2b1/0x3d0\n  ksys_write+0x4e/0xb0\n  do_syscall_64+0x5b/0x160\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe top stacktrace is showing nvme_timeout() called to handle nvme\ncommand timeout. timeout handler is trying to disable the controller and\nas a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not\nto call queue callback handlers. The thread is stuck waiting for\nset-\u003etag_list_lock as it tries to walk the queues in set-\u003etag_list.\n\nThe lock is held by the second thread in the bottom stack which is\nwaiting for one of queues to be frozen. The queue usage counter will\ndrop to zero after nvme_timeout() finishes, and this will not happen\nbecause the thread will wait for this mutex forever.\n\nGiven that [un]quiescing queue is an operation that does not need to\nsleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking\nset-\u003etag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU\nsafe list operations. Also, delete INIT_LIST_HEAD(\u0026q-\u003etag_set_list)\nin blk_mq_del_queue_tag_set() because we can not re-initialize it while\nthe list is being traversed under RCU. The deleted queue will not be\nadded/deleted to/from a tagset and it will be freed in blk_free_queue()\nafter the end of RCU grace period.","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":"block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set-\u003etag_list_lock","id":"CVE-2025-68756","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"race_condition","year":"2025"},"n_packages":0,"n_references":5,"next":{"headline":"drm/vgem-fence: Fix potential deadlock on release","id":"CVE-2025-68757"},"packages":[],"prev":{"headline":"staging: most: remove broken i2c driver","id":"CVE-2025-68755"},"products":["Linux"],"published":"2026-01-05","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-05-11","vendors":["Linux"]},"summary":"A race condition in the Linux kernel block layer can cause a deadlock, leading to a denial of service.","url":"https://insights.sbomify.com/CVE-2025-68756/"}