On 2/28/23 9:40 PM, zhongjinghua wrote:
>> 在 2023/2/13 11:43, Zhong Jinghua 写道:
>>> From: Zhong Jinghua <zhongjinghua@xxxxxxxxxx>
>>>
>>> A use-after-free problem like below:
>>>
>>> BUG: KASAN: use-after-free in scsi_target_reap+0x6c/0x70
>>>
>>> Workqueue: scsi_wq_1 __iscsi_unbind_session [scsi_transport_iscsi]
>>> Call trace:
>>> dump_backtrace+0x0/0x320
>>> show_stack+0x24/0x30
>>> dump_stack+0xdc/0x128
>>> print_address_description+0x68/0x278
>>> kasan_report+0x1e4/0x308
>>> __asan_report_load4_noabort+0x30/0x40
>>> scsi_target_reap+0x6c/0x70
>>> scsi_remove_target+0x430/0x640
>>> __iscsi_unbind_session+0x164/0x268 [scsi_transport_iscsi]
>>> process_one_work+0x67c/0x1350
>>> worker_thread+0x370/0xf90
>>> kthread+0x2a4/0x320
>>> ret_from_fork+0x10/0x18
>>>
>>> The problem is caused by a concurrency scenario:
>>>
>>> T0: delete target
>>> // echo 1 > /sys/devices/platform/host1/session1/target1:0:0/1:0:0:1/delete
>>> T1: logout
>>> // iscsiadm -m node --logout
>>>
>>> T0 T1
>>> sdev_store_delete
>>> scsi_remove_device
>>> device_remove_file
>>> __scsi_remove_device
>>> __iscsi_unbind_session
>>> scsi_remove_target
>>> spin_lock_irqsave
>>> list_for_each_entry
>>> scsi_target_reap // starget->reaf 1 -> 0
>>> kref_get(&starget->reap_ref);
>>> // warn use-after-free.
>>> spin_unlock_irqrestore
>>> scsi_target_reap_ref_release
>>> scsi_target_destroy
>>> ... // delete starget
>>> scsi_target_reap
>>> // UAF
>>>
>>> When T0 reduces the reference count to 0, but has not been released,
>>> T1 can still enter list_for_each_entry, and then kref_get reports UAF.
>>>
>>> Fix it by using kref_get_unless_zero() to check for a reference count of
>>> 0.
>>>
>>> Signed-off-by: Zhong Jinghua <zhongjinghua@xxxxxxxxxx>
>>> ---
>>> drivers/scsi/scsi_sysfs.c | 12 +++++++++++-
>>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
>>> index e7893835b99a..0ad357ff4c59 100644
>>> --- a/drivers/scsi/scsi_sysfs.c
>>> +++ b/drivers/scsi/scsi_sysfs.c
>>> @@ -1561,7 +1561,17 @@ void scsi_remove_target(struct device *dev)
>>> starget->state == STARGET_CREATED_REMOVE)
>>> continue;
>>> if (starget->dev.parent == dev || &starget->dev == dev) {
>>> - kref_get(&starget->reap_ref);
>>> +
>>> + /*
>>> + * If starget->reap_ref is reduced to 0, it means
>>> + * that other processes are releasing it and
>>> + * there is no need to delete it again
>>> + */
>>> + if (!kref_get_unless_zero(&starget->reap_ref)) {
>>> + spin_unlock_irqrestore(shost->host_lock, flags);
>>> + goto restart;
>>> + }
>>> +
Patch looks ok.
Is there another bug in the existing kref_get_unless_zero(&starget->reap_ref)
call in scsi_alloc_target?
I think scsi_alloc_target can find the target on the __targets list, and
it's call to kref_get_unless_zero will succeed if we are only above getting
our own ref (we have not done __scsi_remove_target and have not done the
scsi_target_reap call at the end of the function).
But if scsi_remove_target has set the target state to STARGET_REMOVE, the thread
that did scsi_alloc_target wouldn't be able to put the target into the correct state
(the scsi_target_add call will see the target state and return). So later if the
driver/transport class did scsi_remove_target again to remove the target that
the scsi_alloc_target call re-added, we see the target->state still in STARGET_REMOVE
and it won't get deleted.
Can we solve both issues at the same time?
