From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B0A41D079C for ; Wed, 2 Oct 2024 15:14:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.177.32 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727882046; cv=none; b=DOTFCEKW8xeI2lN2LuXLAFyyTK0YfwgNE+wIBiN9Xe6v9jinmqp8TaSOgX2rICeGzW4fVjKgleY6qba1fXCzQL4vsWP17A7LPuWtlnmUosPFy8t5zpKAFviFpEVWsk6v/+NiX+yw8uwsr+Qsx/kj94uWlRfF7aqDBCmpDL6KYpQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727882046; c=relaxed/simple; bh=y9DaG/6w+goHtLb6afSPEKJaKjXSIqtMRRDJ3ovYonU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=BO45gOkptSPKxQ/f29stx6x9fwT2ZL9u3DI4cgM4uEAdUvQpWEvIkeUfMt2jbismA+Ocjw44H2u1ez1GY31oXOB7LrsqYXzwhmWrXPaG4BHcz4wWUN9vaFYFFaN74FMC+UEENFk9IvOpZTMabwW/lgSH1JWznLAQTBD4nH9V8cU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=nhZSpQJW; arc=none smtp.client-ip=205.220.177.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="nhZSpQJW" Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 492Cd49J011627; Wed, 2 Oct 2024 15:13:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; s=corp-2023-11-20; bh=j BHMtJEWWaCLYlauIWrCh57fWSNcC4qR3AuXecieg8M=; b=nhZSpQJWcOsh1M5LL vjemyva/AzIKMqeeh8vw6xzwdz6AI55UXsgM3VvMt3bAj/VlUze3cgpE/1jXel1K 77dkM0kSG0VP5LtlfGDV41CV/02zDkfG02FXkcRIe3xAvIPy2d5lZLeuYJZdwt+m /jUV6sjjoCFWfcy6QOHcdanJzTB7GHuQAenwRoH5SkPiFUO6mJUkfTNWIw4Urpyw zSRhwd4a+1rV+8m0dIU9mBvae98a8uPC9HKqSFyx4bC529+T10QFVtZbEjO6qHlS 9IIqeRNO9opBmGQ8xkdEqa64xkZAPvgbCexxM189uFsO+f/Qax041GE/1cP4SWyv D7c4A== Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 41x8k39pw1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 02 Oct 2024 15:13:43 +0000 (GMT) Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 492F56C1028435; Wed, 2 Oct 2024 15:13:42 GMT Received: from pps.reinject (localhost [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 41x8897au8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 02 Oct 2024 15:13:42 +0000 Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 492FCqrZ028673; Wed, 2 Oct 2024 15:13:41 GMT Received: from localhost.localdomain (dhcp-10-175-43-118.vpn.oracle.com [10.175.43.118]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTP id 41x88979xb-4; Wed, 02 Oct 2024 15:13:40 +0000 From: Vegard Nossum To: Greg Kroah-Hartman Cc: stable@vger.kernel.org, pavel@denx.de, cengiz.can@canonical.com, mheyne@amazon.de, mngyadam@amazon.com, kuntal.nayak@broadcom.com, ajay.kaher@broadcom.com, zsm@chromium.org, dan.carpenter@linaro.org, shivani.agarwal@broadcom.com, Yu Kuai , Yi Zhang , Zhu Yanjun , Jens Axboe , Harshit Mogalapalli , Vegard Nossum Subject: [PATCH RFC 6.6.y 14/15] null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues' Date: Wed, 2 Oct 2024 17:12:35 +0200 Message-Id: <20241002151236.11787-4-vegard.nossum@oracle.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241002151236.11787-1-vegard.nossum@oracle.com> References: <20241002150606.11385-1-vegard.nossum@oracle.com> <20241002151236.11787-1-vegard.nossum@oracle.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-10-02_15,2024-09-30_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 phishscore=0 suspectscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2408220000 definitions=main-2410020111 X-Proofpoint-GUID: jdQaNr8r20ab2apuMoShMW52hiwcq96P X-Proofpoint-ORIG-GUID: jdQaNr8r20ab2apuMoShMW52hiwcq96P From: Yu Kuai [ Upstream commit a2db328b0839312c169eb42746ec46fc1ab53ed2 ] Writing 'power' and 'submit_queues' concurrently will trigger kernel panic: Test script: modprobe null_blk nr_devices=0 mkdir -p /sys/kernel/config/nullb/nullb0 while true; do echo 1 > submit_queues; echo 4 > submit_queues; done & while true; do echo 1 > power; echo 0 > power; done Test result: BUG: kernel NULL pointer dereference, address: 0000000000000148 Oops: 0000 [#1] PREEMPT SMP RIP: 0010:__lock_acquire+0x41d/0x28f0 Call Trace: lock_acquire+0x121/0x450 down_write+0x5f/0x1d0 simple_recursive_removal+0x12f/0x5c0 blk_mq_debugfs_unregister_hctxs+0x7c/0x100 blk_mq_update_nr_hw_queues+0x4a3/0x720 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x79/0xf0 [null_blk] configfs_write_iter+0x119/0x1e0 vfs_write+0x326/0x730 ksys_write+0x74/0x150 This is because del_gendisk() can concurrent with blk_mq_update_nr_hw_queues(): nullb_device_power_store nullb_apply_submit_queues null_del_dev del_gendisk nullb_update_nr_hw_queues if (!dev->nullb) // still set while gendisk is deleted return 0 blk_mq_update_nr_hw_queues dev->nullb = NULL Fix this problem by resuing the global mutex to protect nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs. Fixes: 45919fbfe1c4 ("null_blk: Enable modifying 'submit_queues' after an instance has been configured") Reported-and-tested-by: Yi Zhang Closes: https://lore.kernel.org/all/CAHj4cs9LgsHLnjg8z06LQ3Pr5cax-+Ps+xT7AP7TPnEjStuwZA@mail.gmail.com/ Signed-off-by: Yu Kuai Reviewed-by: Zhu Yanjun Link: https://lore.kernel.org/r/20240523153934.1937851-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe (cherry picked from commit a2db328b0839312c169eb42746ec46fc1ab53ed2) [Harshit: CVE-2024-36478; Resolve conflicts due to missing commit: e440626b1caf ("null_blk: pass queue_limits to blk_mq_alloc_disk") in 6.6.y] Signed-off-by: Harshit Mogalapalli Signed-off-by: Vegard Nossum --- drivers/block/null_blk/main.c | 40 +++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 14 deletions(-) diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/main.c index 85ab763184b31..0764dcc2e25f7 100644 --- a/drivers/block/null_blk/main.c +++ b/drivers/block/null_blk/main.c @@ -392,13 +392,25 @@ static int nullb_update_nr_hw_queues(struct nullb_device *dev, static int nullb_apply_submit_queues(struct nullb_device *dev, unsigned int submit_queues) { - return nullb_update_nr_hw_queues(dev, submit_queues, dev->poll_queues); + int ret; + + mutex_lock(&lock); + ret = nullb_update_nr_hw_queues(dev, submit_queues, dev->poll_queues); + mutex_unlock(&lock); + + return ret; } static int nullb_apply_poll_queues(struct nullb_device *dev, unsigned int poll_queues) { - return nullb_update_nr_hw_queues(dev, dev->submit_queues, poll_queues); + int ret; + + mutex_lock(&lock); + ret = nullb_update_nr_hw_queues(dev, dev->submit_queues, poll_queues); + mutex_unlock(&lock); + + return ret; } NULLB_DEVICE_ATTR(size, ulong, NULL); @@ -444,28 +456,31 @@ static ssize_t nullb_device_power_store(struct config_item *item, if (ret < 0) return ret; + ret = count; + mutex_lock(&lock); if (!dev->power && newp) { if (test_and_set_bit(NULLB_DEV_FL_UP, &dev->flags)) - return count; + goto out; + ret = null_add_dev(dev); if (ret) { clear_bit(NULLB_DEV_FL_UP, &dev->flags); - return ret; + goto out; } set_bit(NULLB_DEV_FL_CONFIGURED, &dev->flags); dev->power = newp; } else if (dev->power && !newp) { if (test_and_clear_bit(NULLB_DEV_FL_UP, &dev->flags)) { - mutex_lock(&lock); dev->power = newp; null_del_dev(dev->nullb); - mutex_unlock(&lock); } clear_bit(NULLB_DEV_FL_CONFIGURED, &dev->flags); } - return count; +out: + mutex_unlock(&lock); + return ret; } CONFIGFS_ATTR(nullb_device_, power); @@ -2153,15 +2168,12 @@ static int null_add_dev(struct nullb_device *dev) nullb->q->queuedata = nullb; blk_queue_flag_set(QUEUE_FLAG_NONROT, nullb->q); - mutex_lock(&lock); rv = ida_alloc(&nullb_indexes, GFP_KERNEL); - if (rv < 0) { - mutex_unlock(&lock); + if (rv < 0) goto out_cleanup_zone; - } + nullb->index = rv; dev->index = rv; - mutex_unlock(&lock); blk_queue_logical_block_size(nullb->q, dev->blocksize); blk_queue_physical_block_size(nullb->q, dev->blocksize); @@ -2185,9 +2197,7 @@ static int null_add_dev(struct nullb_device *dev) if (rv) goto out_ida_free; - mutex_lock(&lock); list_add_tail(&nullb->list, &nullb_list); - mutex_unlock(&lock); pr_info("disk %s created\n", nullb->disk_name); @@ -2236,7 +2246,9 @@ static int null_create_dev(void) if (!dev) return -ENOMEM; + mutex_lock(&lock); ret = null_add_dev(dev); + mutex_unlock(&lock); if (ret) { null_free_dev(dev); return ret; -- 2.34.1