Linux Kernel up to 6.6.116/6.12.57/6.17.7 blk-cgroup blkg_conf_prep deadlock

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 4.6 | $0-$5k | 0.00 |
Summary
A vulnerability classified as critical was found in Linux Kernel up to 6.6.116/6.12.57/6.17.7. This issue affects the function blkg_conf_prep of the component blk-cgroup. The manipulation results in deadlock.
This vulnerability is cataloged as CVE-2025-68178. There is no exploit available.
Upgrading the affected component is advised.
Details
A vulnerability was found in Linux Kernel up to 6.6.116/6.12.57/6.17.7. It has been classified as critical. Affected is the function blkg_conf_prep of the component blk-cgroup. The manipulation with an unknown input leads to a deadlock vulnerability. CWE is classifying the issue as CWE-833. The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock. This is going to have an impact on availability. CVE summarizes:
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix possible deadlock while configuring policy Following deadlock can be triggered easily by lockdep: WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted ------------------------------------------------------ check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180 but task is already holding lock: ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30 -> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock); Root cause is that queue_usage_counter is grabbed with rq_qos_mutex held in blkg_conf_prep(), while queue should be freezed before rq_qos_mutex from other context. The blk_queue_enter() from blkg_conf_prep() is used to protect against policy deactivation, which is already protected with blkcg_mutex, hence convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile, consider that blkcg_mutex is held after queue is freezed from policy deactivation, also convert blkg_alloc() to use GFP_NOIO.
The advisory is available at git.kernel.org. This vulnerability is traded as CVE-2025-68178 since 12/16/2025. The exploitability is told to be difficult. Technical details are known, but there is no available exploit.
The vulnerability scanner Nessus provides a plugin with the ID 298917 (SUSE SLES15 Security Update : kernel (SUSE-SU-2026:0472-1)), which helps to determine the existence of the flaw in a target environment.
Upgrading to version 6.6.117, 6.12.58 or 6.17.8 eliminates this vulnerability. Applying the patch e1729523759cda2c0afb76b1c88e0d2f2ef5b7cb/56ac639d6fa6fbb99caee74ee1c7276fc9bb47ed/0585b24d71197dd9ee8cf79c168a31628c631960/5d726c4dbeeddef612e6bed27edd29733f4d13af is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.
The vulnerability is also documented in the databases at Tenable (298917) and CERT Bund (WID-SEC-2025-2868). If you want to get best quality of vulnerability data, you may have to visit VulDB.
Affected
- Debian Linux
- Amazon Linux 2
- Red Hat Enterprise Linux
- Ubuntu Linux
- SUSE Linux
- Oracle Linux
- SUSE openSUSE
- RESF Rocky Linux
- Open Source Linux Kernel
Product
Type
Vendor
Name
Version
- 6.6.116
- 6.12.0
- 6.12.1
- 6.12.2
- 6.12.3
- 6.12.4
- 6.12.5
- 6.12.6
- 6.12.7
- 6.12.8
- 6.12.9
- 6.12.10
- 6.12.11
- 6.12.12
- 6.12.13
- 6.12.14
- 6.12.15
- 6.12.16
- 6.12.17
- 6.12.18
- 6.12.19
- 6.12.20
- 6.12.21
- 6.12.22
- 6.12.23
- 6.12.24
- 6.12.25
- 6.12.26
- 6.12.27
- 6.12.28
- 6.12.29
- 6.12.30
- 6.12.31
- 6.12.32
- 6.12.33
- 6.12.34
- 6.12.35
- 6.12.36
- 6.12.37
- 6.12.38
- 6.12.39
- 6.12.40
- 6.12.41
- 6.12.42
- 6.12.43
- 6.12.44
- 6.12.45
- 6.12.46
- 6.12.47
- 6.12.48
- 6.12.49
- 6.12.50
- 6.12.51
- 6.12.52
- 6.12.53
- 6.12.54
- 6.12.55
- 6.12.56
- 6.12.57
- 6.17.0
- 6.17.1
- 6.17.2
- 6.17.3
- 6.17.4
- 6.17.5
- 6.17.6
- 6.17.7
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 4.8VulDB Meta Temp Score: 4.6
VulDB Base Score: 4.8
VulDB Temp Score: 4.6
VulDB Vector: 🔒
VulDB Reliability: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: DeadlockCWE: CWE-833 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒
Physical: No
Local: No
Remote: Partially
Availability: 🔒
Status: Not defined
EPSS Score: 🔒
EPSS Percentile: 🔒
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Nessus ID: 298917
Nessus Name: SUSE SLES15 Security Update : kernel (SUSE-SU-2026:0472-1)
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔒
Upgrade: Kernel 6.6.117/6.12.58/6.17.8
Patch: e1729523759cda2c0afb76b1c88e0d2f2ef5b7cb/56ac639d6fa6fbb99caee74ee1c7276fc9bb47ed/0585b24d71197dd9ee8cf79c168a31628c631960/5d726c4dbeeddef612e6bed27edd29733f4d13af
Timeline
12/16/2025 Advisory disclosed12/16/2025 CVE reserved
12/16/2025 VulDB entry created
02/21/2026 VulDB entry last update
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CVE: CVE-2025-68178 (🔒)
GCVE (CVE): GCVE-0-2025-68178
GCVE (VulDB): GCVE-100-336714
CERT Bund: WID-SEC-2025-2868 - Linux Kernel: Mehrere Schwachstellen
Entry
Created: 12/16/2025 15:04Updated: 02/21/2026 07:23
Changes: 12/16/2025 15:04 (59), 01/14/2026 07:52 (7), 01/19/2026 21:29 (1), 02/03/2026 02:22 (1), 02/14/2026 23:00 (2), 02/21/2026 07:23 (1)
Complete: 🔍
Cache ID: 216::103
If you want to get best quality of vulnerability data, you may have to visit VulDB.
No comments yet. Languages: en.
Please log in to comment.