Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:[EOL][EOL]blk-cgroup: fix possible deadlock while configuring policy[EOL][EOL]Following deadlock can be triggered easily by lockdep:[EOL][EOL]WARNING: possible circular locking dependency detected[EOL]6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted[EOL]------------------------------------------------------[EOL]check/1334 is trying to acquire lock:[EOL]ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180[EOL][EOL]but task is already holding lock:[EOL]ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110[EOL][EOL]which lock already depends on the new lock.[EOL][EOL]the existing dependency chain (in reverse order) is:[EOL][EOL]-> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}:[EOL]       blk_queue_enter+0x40b/0x470[EOL]       blkg_conf_prep+0x7b/0x3c0[EOL]       tg_set_limit+0x10a/0x3e0[EOL]       cgroup_file_write+0xc6/0x420[EOL]       kernfs_fop_write_iter+0x189/0x280[EOL]       vfs_write+0x256/0x490[EOL]       ksys_write+0x83/0x190[EOL]       __x64_sys_write+0x21/0x30[EOL]       x64_sys_call+0x4608/0x4630[EOL]       do_syscall_64+0xdb/0x6b0[EOL]       entry_SYSCALL_64_after_hwframe+0x76/0x7e[EOL][EOL]-> #1 (&q->rq_qos_mutex){+.+.}-{4:4}:[EOL]       __mutex_lock+0xd8/0xf50[EOL]       mutex_lock_nested+0x2b/0x40[EOL]       wbt_init+0x17e/0x280[EOL]       wbt_enable_default+0xe9/0x140[EOL]       blk_register_queue+0x1da/0x2e0[EOL]       __add_disk+0x38c/0x5d0[EOL]       add_disk_fwnode+0x89/0x250[EOL]       device_add_disk+0x18/0x30[EOL]       virtblk_probe+0x13a3/0x1800[EOL]       virtio_dev_probe+0x389/0x610[EOL]       really_probe+0x136/0x620[EOL]       __driver_probe_device+0xb3/0x230[EOL]       driver_probe_device+0x2f/0xe0[EOL]       __driver_attach+0x158/0x250[EOL]       bus_for_each_dev+0xa9/0x130[EOL]       driver_attach+0x26/0x40[EOL]       bus_add_driver+0x178/0x3d0[EOL]       driver_register+0x7d/0x1c0[EOL]       __register_virtio_driver+0x2c/0x60[EOL]       virtio_blk_init+0x6f/0xe0[EOL]       do_one_initcall+0x94/0x540[EOL]       kernel_init_freeable+0x56a/0x7b0[EOL]       kernel_init+0x2b/0x270[EOL]       ret_from_fork+0x268/0x4c0[EOL]       ret_from_fork_asm+0x1a/0x30[EOL][EOL]-> #0 (&q->sysfs_lock){+.+.}-{4:4}:[EOL]       __lock_acquire+0x1835/0x2940[EOL]       lock_acquire+0xf9/0x450[EOL]       __mutex_lock+0xd8/0xf50[EOL]       mutex_lock_nested+0x2b/0x40[EOL]       blk_unregister_queue+0x53/0x180[EOL]       __del_gendisk+0x226/0x690[EOL]       del_gendisk+0xba/0x110[EOL]       sd_remove+0x49/0xb0 [sd_mod][EOL]       device_remove+0x87/0xb0[EOL]       device_release_driver_internal+0x11e/0x230[EOL]       device_release_driver+0x1a/0x30[EOL]       bus_remove_device+0x14d/0x220[EOL]       device_del+0x1e1/0x5a0[EOL]       __scsi_remove_device+0x1ff/0x2f0[EOL]       scsi_remove_device+0x37/0x60[EOL]       sdev_store_delete+0x77/0x100[EOL]       dev_attr_store+0x1f/0x40[EOL]       sysfs_kf_write+0x65/0x90[EOL]       kernfs_fop_write_iter+0x189/0x280[EOL]       vfs_write+0x256/0x490[EOL]       ksys_write+0x83/0x190[EOL]       __x64_sys_write+0x21/0x30[EOL]       x64_sys_call+0x4608/0x4630[EOL]       do_syscall_64+0xdb/0x6b0[EOL]       entry_SYSCALL_64_after_hwframe+0x76/0x7e[EOL][EOL]other info that might help us debug this:[EOL][EOL]Chain exists of:[EOL]  &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3[EOL][EOL] Possible unsafe locking scenario:[EOL][EOL]       CPU0                    CPU1[EOL]       ----                    ----[EOL]  lock(&q->q_usage_counter(queue)#3);[EOL]                               lock(&q->rq_qos_mutex);[EOL]                               lock(&q->q_usage_counter(queue)#3);[EOL]  lock(&q->sysfs_lock);[EOL][EOL]Root cause is that queue_usage_counter is grabbed with rq_qos_mutex[EOL]held in blkg_conf_prep(), while queue should be freezed before[EOL]rq_qos_mutex from other context.[EOL][EOL]The blk_queue_enter() from blkg_conf_prep() is used to protect against[EOL]policy deactivation, which is already protected with blkcg_mutex, hence[EOL]convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile,[EOL]consider that blkcg_mutex is held after queue is freezed from policy[EOL]deactivation, also convert blkg_alloc() to use GFP_NOIO.