fkie_cve-2025-68178
Vulnerability from fkie_nvd
Published
2025-12-16 14:15
Modified
2025-12-18 15:08
Severity ?
Summary
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/0585b24d71197dd9ee8cf79c168a31628c631960
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/56ac639d6fa6fbb99caee74ee1c7276fc9bb47ed
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5d726c4dbeeddef612e6bed27edd29733f4d13af
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/e1729523759cda2c0afb76b1c88e0d2f2ef5b7cb
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: fix possible deadlock while configuring policy\n\nFollowing deadlock can be triggered easily by lockdep:\n\nWARNING: possible circular locking dependency detected\n6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted\n------------------------------------------------------\ncheck/1334 is trying to acquire lock:\nff1100011d9d0678 (\u0026q-\u003esysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180\n\nbut task is already holding lock:\nff1100011d9d00e0 (\u0026q-\u003eq_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #2 (\u0026q-\u003eq_usage_counter(queue)#3){++++}-{0:0}:\n       blk_queue_enter+0x40b/0x470\n       blkg_conf_prep+0x7b/0x3c0\n       tg_set_limit+0x10a/0x3e0\n       cgroup_file_write+0xc6/0x420\n       kernfs_fop_write_iter+0x189/0x280\n       vfs_write+0x256/0x490\n       ksys_write+0x83/0x190\n       __x64_sys_write+0x21/0x30\n       x64_sys_call+0x4608/0x4630\n       do_syscall_64+0xdb/0x6b0\n       entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u003e #1 (\u0026q-\u003erq_qos_mutex){+.+.}-{4:4}:\n       __mutex_lock+0xd8/0xf50\n       mutex_lock_nested+0x2b/0x40\n       wbt_init+0x17e/0x280\n       wbt_enable_default+0xe9/0x140\n       blk_register_queue+0x1da/0x2e0\n       __add_disk+0x38c/0x5d0\n       add_disk_fwnode+0x89/0x250\n       device_add_disk+0x18/0x30\n       virtblk_probe+0x13a3/0x1800\n       virtio_dev_probe+0x389/0x610\n       really_probe+0x136/0x620\n       __driver_probe_device+0xb3/0x230\n       driver_probe_device+0x2f/0xe0\n       __driver_attach+0x158/0x250\n       bus_for_each_dev+0xa9/0x130\n       driver_attach+0x26/0x40\n       bus_add_driver+0x178/0x3d0\n       driver_register+0x7d/0x1c0\n       __register_virtio_driver+0x2c/0x60\n       virtio_blk_init+0x6f/0xe0\n       do_one_initcall+0x94/0x540\n       kernel_init_freeable+0x56a/0x7b0\n       kernel_init+0x2b/0x270\n       ret_from_fork+0x268/0x4c0\n       ret_from_fork_asm+0x1a/0x30\n\n-\u003e #0 (\u0026q-\u003esysfs_lock){+.+.}-{4:4}:\n       __lock_acquire+0x1835/0x2940\n       lock_acquire+0xf9/0x450\n       __mutex_lock+0xd8/0xf50\n       mutex_lock_nested+0x2b/0x40\n       blk_unregister_queue+0x53/0x180\n       __del_gendisk+0x226/0x690\n       del_gendisk+0xba/0x110\n       sd_remove+0x49/0xb0 [sd_mod]\n       device_remove+0x87/0xb0\n       device_release_driver_internal+0x11e/0x230\n       device_release_driver+0x1a/0x30\n       bus_remove_device+0x14d/0x220\n       device_del+0x1e1/0x5a0\n       __scsi_remove_device+0x1ff/0x2f0\n       scsi_remove_device+0x37/0x60\n       sdev_store_delete+0x77/0x100\n       dev_attr_store+0x1f/0x40\n       sysfs_kf_write+0x65/0x90\n       kernfs_fop_write_iter+0x189/0x280\n       vfs_write+0x256/0x490\n       ksys_write+0x83/0x190\n       __x64_sys_write+0x21/0x30\n       x64_sys_call+0x4608/0x4630\n       do_syscall_64+0xdb/0x6b0\n       entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nother info that might help us debug this:\n\nChain exists of:\n  \u0026q-\u003esysfs_lock --\u003e \u0026q-\u003erq_qos_mutex --\u003e \u0026q-\u003eq_usage_counter(queue)#3\n\n Possible unsafe locking scenario:\n\n       CPU0                    CPU1\n       ----                    ----\n  lock(\u0026q-\u003eq_usage_counter(queue)#3);\n                               lock(\u0026q-\u003erq_qos_mutex);\n                               lock(\u0026q-\u003eq_usage_counter(queue)#3);\n  lock(\u0026q-\u003esysfs_lock);\n\nRoot cause is that queue_usage_counter is grabbed with rq_qos_mutex\nheld in blkg_conf_prep(), while queue should be freezed before\nrq_qos_mutex from other context.\n\nThe blk_queue_enter() from blkg_conf_prep() is used to protect against\npolicy deactivation, which is already protected with blkcg_mutex, hence\nconvert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile,\nconsider that blkcg_mutex is held after queue is freezed from policy\ndeactivation, also convert blkg_alloc() to use GFP_NOIO."
    }
  ],
  "id": "CVE-2025-68178",
  "lastModified": "2025-12-18T15:08:25.907",
  "metrics": {},
  "published": "2025-12-16T14:15:49.760",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/0585b24d71197dd9ee8cf79c168a31628c631960"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/56ac639d6fa6fbb99caee74ee1c7276fc9bb47ed"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5d726c4dbeeddef612e6bed27edd29733f4d13af"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/e1729523759cda2c0afb76b1c88e0d2f2ef5b7cb"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.