From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A39F3A875D for ; Fri, 14 Aug 2026 16:10:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786723805; cv=none; b=PIcPVAzmqM4NDudxs8/Q4CPkY2K5J/agF3c882ZrsliukMjNtgNfTZk3J43/Ixz1CZDrRQH+hrWfGl3YSqHH7uJx85I7Srpg7OcplkoPyEszvR8Z3cAcWlJ6evSCmTCNI3u7KJk/FHDXlW+jYuNMY02DqfeFMXunRxWxR3M7vcg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786723805; c=relaxed/simple; bh=ed9wtRmkoP7Wdhmi/WVgPoAqFaryqSGPXBlc+TkS3Uo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=TaxDvj4Xor1liVWf4cwmT4+q7EE+I9Xn5GizBn053zlB7I4VWtS3SORHYuBN1oOQQN65o9RThonj0fRcW3mRxjTBNaI5TjpVMjuzpaOd5S99+cGTsA+PXm+js5tLxyEvQS3ohHdTOM/7bRkkTqrYCw29OiuJ3jAvSil9N7TQx98= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JbEAjc8P; arc=none smtp.client-ip=209.85.128.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JbEAjc8P" Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-8201447e8cdso21900407b3.3 for ; Fri, 14 Aug 2026 09:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786723800; x=1787328600; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=yxq818myupXhtwcrZIn4DVpAwIlvbEBii869YtzAJT8=; b=JbEAjc8PzCCLWVHjL+l2Ag8GVALJVKjRlUkr7At05fKWnZ3JnM9rk5cqip/vo+qWcG yMc2dQfgcVb3Qv7pJ9ra2VxpsYgBFEJutMGqO+qhqC0pvW1mwIJNmUrfo2qfZkyB33bk waU4VoB6ETRLKhRJ93/z+EvDBQmuvF7y1TIXQzB1CsPejqxVzCscgiYdJLqeVjnW5Du3 EPZyZQKu/K1Nej1wXEDi0kBnDteNBf5/ZBPcnBWHSTLOKkRPI8htnuExEoWozmdmiO+B Q6aAA6KgX1FcwHjgELLxIPqTk5Alg1kuTkRjbHpehVRDLwkXt3B6NhVMQbJfN0Q1AAU+ uMiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786723800; x=1787328600; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=yxq818myupXhtwcrZIn4DVpAwIlvbEBii869YtzAJT8=; b=fl4I9gqqkQTqZoHXhXJ4IMkx/h20Ntm34h3tU0GJrs3MRSpZ3OATHF6GnG/H24lgNi IcdhM2s3296cLCyxfXZxRamYLZp+7mvng7Ak5mrpKOusTgOnuuy3p5QnGU4Fj5k5sLKj 8IZo6yQbeuv+cdFy3EtF9cAgJ0/Aca4WAvei0EB1hhudwz+Q3uJ8GD6dYegBNCL0vbZu vY7JIq7dnk+qH3o7NOZ8Ai5Nk/88c97tczeuXSjsYY0NTOaeDKd5PE5NnY4yY9ILtHi6 RCX9f4t6S24cJ06zPTt571tZEXpWYRm5bgmiMcefZuhTHbg7ibJSDswzsmyHieaQ7GaV /9iw== X-Forwarded-Encrypted: i=1; AHgh+Rrm5+pg9ZhUlO9RdgoRGXjsXe4IIPg4fZO3m70N+1oWOliivViE/pLKItAElm1UPXkzz2MQzyj0hPYiah0=@vger.kernel.org X-Gm-Message-State: AOJu0YyFq6NG8nXg5KpIgahs77R1ZUzVtrral78w0rJ9ndHTQkBMNX3M w8Bpx7UYIvDBzyiRiQ3t3HCr8rku31a6FcwAAHiW8oi1s+ieiVATEDBh X-Gm-Gg: AR+sD13lGXlXFuTCe3MFKZ85DhqyDOqZphEzt+5yzNN1/Kg8c5BlXCHhD4+7VBGAa3M PaNBAAVK2MjOi2iGL3ietNRREj5fl8HNp06/t/93LbQ3Dl0sLKwR/HtttWCFWzYT+dFW5tjUQg0 dosM1FAU3Er6yYxlFQ98fQpTIMhtUseAd3s2CCbdUJs+84q27ciirDfoCT39MW6KkzzPxwQgpP4 Ip7LOgI44z9NVr08GQfoGIfUqf9U2/D2AbXIhZbYKSZUn4duNRp8WOVKKTjKZPG3o2RCt+Fm7Bz H8MCIybx72yAYOFoZTuFXPlUmOCxArDNQ9VyB0GTZ+LRFcEHHAahqWX5SwO4xG921JLelgRroai z983fb7GM/NWwlvuX0YeZ+6MYO3ryRRzR66DkelslJJTeU+w7eDo8MrFZY2cTO7mjB4HaayfN0k NjAOrJywF9wJxE0wwbdeLLUfLHdZf/cOM2X/h/4OajyyKwVy/h0PGRzLUH9ddNTYyXhPYQF6DNC vka09nrx/yYh7aD5w== X-Received: by 2002:a05:690c:6310:b0:7cf:d242:d94a with SMTP id 00721157ae682-8371431484fmr27885107b3.25.1786723800495; Fri, 14 Aug 2026 09:10:00 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 00721157ae682-836c261a59csm15358717b3.36.2026.08.14.09.09.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 09:10:00 -0700 (PDT) From: Chao Shi To: kbusch@kernel.org Cc: hch@lst.de, sagi@grimberg.me, axboe@kernel.dk, joshi.k@samsung.com, weizhu@fiu.edu, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Chao Shi Subject: [PATCH] nvme: reject zoned namespaces whose zone info query failed Date: Fri, 14 Aug 2026 12:09:54 -0400 Message-ID: <20260814160954.2839507-1-coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit nvme_query_zone_info() returns either a negative errno or a positive NVMe status code, but nvme_update_ns_info_block() only tests for the negative case: ret = nvme_query_zone_info(ns, lbaf, &zi); if (ret < 0) goto out; If the Identify Namespace (I/O Command Set specific) command fails on the device, or if the Identify Controller command issued by nvme_set_max_append() fails, the positive status falls through and setup continues with the zero-initialized "struct nvme_zone_info zi = {}". nvme_update_zone_info() then configures the queue from those zeroes: lim->features |= BLK_FEAT_ZONED; lim->max_open_zones = zi->max_open_zones; lim->max_active_zones = zi->max_active_zones; lim->chunk_sectors = ns->head->zsze = nvme_lba_to_sect(ns->head, zi->zone_size); so the queue ends up marked zoned with a zone size of zero. This is reachable by a malicious NVMe device, a buggy firmware, or an attacker-controlled NVMe-oF target that fails this one command. blk_validate_zoned_limits() does not look at chunk_sectors, so the limits commit succeeds. blk_revalidate_disk_zones() does reject the zero zone size, but by then the limits are committed and the queue is unfrozen and nothing rolls them back, so block devices that are already open keep submitting I/O to a zoned queue whose zone size is zero. disk_zone_no() then shifts by ilog2(0): nvme0n1: Invalid non power of two zone size (0) UBSAN: shift-out-of-bounds in include/linux/blkdev.h:747:16 shift exponent -1 is negative disk_zone_no include/linux/blkdev.h:747 [inline] bio_zone_no include/linux/blkdev.h:1052 [inline] bio_straddles_zones include/linux/blkdev.h:1058 [inline] blk_zone_wplug_handle_write block/blk-zoned.c:1423 [inline] blk_zone_plug_bio.cold+0x25/0x1c8 block/blk-zoned.c:1605 blk_mq_submit_bio+0x18fb/0x2870 block/blk-mq.c:3196 __submit_bio+0x315/0xa70 block/blk-core.c:637 submit_bio_noacct_nocheck+0x488/0xba0 block/blk-core.c:755 submit_bh_wbc+0x575/0x740 fs/buffer.c:2824 __block_write_full_folio+0x728/0xdd0 fs/buffer.c:1933 wb_workfn+0x8c9/0xd50 fs/fs-writeback.c:2403 Before commit c85c9ab926a5 ("nvme: split nvme_update_zone_info") the caller tested "if (ret)" and bailed out on any non-zero return. Restore that behaviour. Fixes: c85c9ab926a5 ("nvme: split nvme_update_zone_info") Cc: stable@vger.kernel.org Cc: Weidong Zhu Found by FuzzNvme. Signed-off-by: Chao Shi --- drivers/nvme/host/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 453c1f0b2dd0..dd7859826d2b 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2417,7 +2417,7 @@ static int nvme_update_ns_info_block(struct nvme_ns *ns, if (IS_ENABLED(CONFIG_BLK_DEV_ZONED) && ns->head->ids.csi == NVME_CSI_ZNS) { ret = nvme_query_zone_info(ns, lbaf, &zi); - if (ret < 0) + if (ret) goto out; } -- 2.43.0