From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25A92C678D4 for ; Mon, 6 Mar 2023 11:35:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 73937280002; Mon, 6 Mar 2023 06:35:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6EAFD280001; Mon, 6 Mar 2023 06:35:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B1BD280002; Mon, 6 Mar 2023 06:35:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4AE84280001 for ; Mon, 6 Mar 2023 06:35:35 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0F0EAAB0E4 for ; Mon, 6 Mar 2023 11:35:35 +0000 (UTC) X-FDA: 80538268230.02.88996D9 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf08.hostedemail.com (Postfix) with ESMTP id B6A61160024 for ; Mon, 6 Mar 2023 11:35:32 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf08.hostedemail.com: domain of zhongjinghua@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=zhongjinghua@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678102533; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=AcVoUM3zjJY0TXLcgNDAz1FGawK4AZZJkNTd+kEhYRA=; b=j8AOAgcym2nW107gM75YyDnAhEbHxcYYpSowiMXowEVgqEgBNig0wax/a5cCaALs2ZHDLJ g/QEi/HOKOfUHroufyezIlKCD9cOALSMKQ4MUCqI2FYpAFnfkiJBv/+tnnsAM5q+UMv7Mx 3oO6iGCSwWKHpIWxCFTC11YC060TM08= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf08.hostedemail.com: domain of zhongjinghua@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=zhongjinghua@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678102533; a=rsa-sha256; cv=none; b=PiyDHFzV6GoqCE9Ke29wGkrJEpYUzC29DFrjukHrGghYb+7mfHVmYfnJpoz0gSPpiIcNFw gRPpX07q12i/G/v5ak0bPLx8z+xmToy8+2Uf2ZABFyr2U9gL7qcETSRsLioaNCXeVgazFf TrtAi3nkqVthzhb+1OQ5Mb1Kf1ArJHc= Received: from kwepemm600002.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4PVbzG1DFtznWDW; Mon, 6 Mar 2023 19:32:42 +0800 (CST) Received: from localhost.localdomain (10.175.127.227) by kwepemm600002.china.huawei.com (7.193.23.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Mon, 6 Mar 2023 19:35:27 +0800 From: Zhong Jinghua To: , , CC: , , , , , Subject: [PATCH-next v2] scsi: fix use-after-free problem in scsi_remove_target Date: Mon, 6 Mar 2023 19:58:40 +0800 Message-ID: <20230306115840.3156157-1-zhongjinghua@huawei.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemm600002.china.huawei.com (7.193.23.29) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B6A61160024 X-Rspam-User: X-Stat-Signature: t48mi7nqj578sjy3ne8pzx357gacbmjf X-HE-Tag: 1678102532-456551 X-HE-Meta: U2FsdGVkX1/1if3L9ZAKVs295Z5dYSgGqlS9QLoeZ3nZPQR8tj8OJM6eIMo8/7S6Slz9iv/T5617rfb3dtR9LiBLzqvWQhYel0t+4hfwVBRpz0u85+vcFS1+yr2YHSu+hnufsxM7ij+mBC9/5lPW5PgBrgAov0j8mVYwxnbIOZMJv0y/FiKHr+dQTqBbDk3QfoAI9attyEHuAW2aY+CdZ1oJvP773D3Gvm67I9TTiE0mvaKiHG4L8r31TBOg82Kg9GGee/NFpcYb9kXOyQcRLGiA1DKUUenqX+2kjVLCj4ngiFNZ/YTDaeeXM1ZteiasWLohNcrqUOEIQ70fUgKq5bPIieWsO3+ktdJfmWk53KAz3UMPLVIWwInBcB0S95OK/e6Lc6xbuHTrwe1OA4VTVtSFTgOQV0MnU7mX7NePyA9szOEDz1apg0KaYxSSrt5xjs5fTeFSoMx2sZpbDOkzFF3vc+xFVIAvpF/nc7i+4EnShJEOAOz0qqbbEqaP7ihLRE3DsDj0T3dUUsUuRv0BW3wUaqaii0jfJtzs3WecaQsRmoGBGTnx6y5dBTmECKG9y+bfN1aAJ5XEC2GJB3rTR3JwAIqd7RCXHHKFsilWzdWD27l9eoFkzIBzvyFcFAmJU2ZGxQM9POY3s1/1BNnj+2evJfxtIwCZzmJic+oFNSuxCi0Ha/wiEy3bm+KSSi8co7aP/RUxhz28i9wI1GZG+5rNZ272t0YtUQFIaYnX09Ic00xOMT2BEOgu8FufF7VffhILv1yBVLuvI5F2no3ZbEmRRnu1jAfigA8b2zdN3tCdr5xU1bGqyp0+A6foPgdMGWMzp9pH7PDsyIJ706YT9xX8KOwDzAEa3bBVuuk8ptAeiM+lJuv7FGkzSA0JEEeCk0gEbQ19Z/5BhBo5dCkvQyr5ORts/xvHlyLOJ+fX+l6awYKXfist9ttjcw2fXMRvL5w8o/MXQazqjK/y3Gx B5Zmp3FU TIMbrDwzwQ0uLCSAU7N5v8jFVR+JIAJUGqZKvU1XD90Ml0ZOsqkUo/fsRu115ntkHL8tRbGNHi8BbOkk/GWx2o6SJ5eYeKfhCUnOeb76LRlCCUA8m/0b8pNks2cQ0JA+y9RqX3UENYjcdX5FV8y23gfqSk4Z8dz35v/xVRhu92Ts60NFvUoNxngcOfJml7PwxGQJ/caZBlJC6QgwCHHfJHaN7OQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.039885, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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->reap_ref 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 --- v2: commit message: "starget->reaf" -> "starget->reap_ref" comment: "If it is reduced to 0, it means that other processes are releasing it and there is no need to delete it again" -> "If the reference count is already zero, skip this target is safe because scsi_target_destroy() will wait until the host lock has been released before freeing starget." drivers/scsi/scsi_sysfs.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index e7893835b99a..12e8ed6d55cb 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -1561,7 +1561,16 @@ 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 the reference count is already zero, skip this + * target is safe because scsi_target_destroy() + * will wait until the host lock has been released + * before freeing starget. + */ + if (!kref_get_unless_zero(&starget->reap_ref)) + continue; + if (starget->state == STARGET_CREATED) starget->state = STARGET_CREATED_REMOVE; else -- 2.31.1