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 F395E4B04B9 for ; Sun, 16 Aug 2026 19:17:36 +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=1786907858; cv=none; b=Ppoi5le2O8mIna92weaqlIcOOJvQE07ycOOVjlIE3ovmpXFRH0nxT2SuoHiBcrEcdbhez5BBsBFls0mWWR3KKvio8+Jp7Mmd6HDVaG9a0HCFoyO7vdskDOx0GU432QAKnu6hfYiiVdQHo8X5xCY+wr+AgGv2f7I6ALA+5YWbGkk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786907858; c=relaxed/simple; bh=T0h1D6+F6G80KEwNjlSZDg0Rlz+RAzRQLdI3ihYaork=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=LQGMc2KcCuXvR6tDYqnfwoGANaM0ssaDmvnXadXwN2in0c8UekzbDgAq/yr1MC+b3IxPbSeGpUDmBtbarSP1O7WACEjXEgXhXsA6MH3FO5Hwojgbjk/UjupCWrXKTDbW5wL44lx4CzdEG5HKC9T1J8mTtc43luEC2PX5I/oFyTo= 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=VQiyfkjY; 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="VQiyfkjY" Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-81ee6b2da98so34125247b3.3 for ; Sun, 16 Aug 2026 12:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786907856; x=1787512656; 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=AISqMB6CvA0Lb35Q0jRjNWDuiHxCP9fPg6wK9jXO2X8=; b=VQiyfkjYp3Nm/sFqtCN5TjUGYwMOxOCAKIWryw9oOtxv3w+Hpi7p3VDhXZ2+hZYsFG nhXxt/Eyg6tmVY0zRTHO6SZ8tmL4h51bNIS1+x5uvao1bEMyXJhhctfnCx03K/2z/Gfg YQxvXNkqMuLTKLW/c3vJT378SiWVeTpzTxxzVb/XwOOLdVkUEzg1lz8lIPlQaaFkCuVS jy3+4g38vll1iI1lGHYSC12lu8PlLf347D34yAVsh/CjGjzcbVkX+9Yhfo3+p+KIAMKZ Zvb3d026i1cBmXISxy6GCbDuRh1/X+Ac0jOoDRwfNwFooxpUkuh8kmnIqApDisc0iasY pQrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786907856; x=1787512656; 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=AISqMB6CvA0Lb35Q0jRjNWDuiHxCP9fPg6wK9jXO2X8=; b=WkdmfyNv4jHxvfKChcO8Ge5NwiawdZ4yy/MzM7/f1iyt+oVcB2q9Z167ksyM6mjVED GTYhftTVr+8vxXZPnD9+puvPyPYzps+fOkmt2KVJXIUOX0YPbud/2pcZOmhl5GvKJu9F AKXKTFOsDwfEFOx3GusOZDPWFBoMY4khaGAEbTFVoN2be56RmKn/6iQK/cGXctCED/9r v6yJtR2hH+g/d9TgJ8WpDNd4J2giN35c5Wwc32AFY1LnVSMZGy5ZLmqZIO0iO42vqDBA AGSRhAtLz1Tdpae9KlqUroWQE2O3CWsE6r8cvSizSPIIo2uBReCL7hA7cqjHhgNuhhRS 517A== X-Forwarded-Encrypted: i=1; AHgh+RqZ/rsneoZ4UA31yeGRnKKjbjOqYFm9B65SYuXdmbXcqWPcHtVDR8qk2mp+qtc0qgMZad3B1ckI31WFWWg=@vger.kernel.org X-Gm-Message-State: AOJu0Yy69Vd+gviQSXeZSUo0/ZVSFC8qtlu02SXf5mjAPrupV4dpwAmF w9cfORILosaXZHE12MUCUqRcK3qveVL5uXhJIIcvRn290U3NENdutZKL X-Gm-Gg: AR+sD13PAUrjLXluGg6z+aI8ZP5m02vowAbYqALOpW0Arbb/P1k07AozXEBdXiQpQX9 F+B/sxOCD8/6toV0e2fsbdDBQrOyP1luotHDvcWSJzX2gI8m/ylaCWPNcCrfJPGsJ7b8L9+Od3P XHUoXY9qPKrKEJbxgFkPOOK9X5Rkto2LJiQYxTklaXbhHng12sMCOuPzDYkoKWF8UcFUu3BL2To pZP2kqK/VvmsqMcf+PXSg9Cw5wfTnTCi3bsRKxti1oAzFzmyMCoYS5h6M8IN3RjMfa8L84xLjWh gRX4814z99mVUXq6N/YrNOfUL9MyAMnUUrRysdKlIzrZ8+rmIYJhePHHhhvd2NF9WrddkBG2Zew zrNuUD0AWiGkFsbGq0j7E96upkJ3rIYqBf2VqfkKcxvzdI3AkhcTxOd5qvhRJC16Gwo6igwiBye M3GrBP7jhM8wCoRa2olSmtVGW/F0h0u58LM74QzAchVLR7a4HjNM2fQtVswWPuHJ6w46EbJslYa xfBw1w= X-Received: by 2002:a05:690c:e292:b0:827:b35:9d5e with SMTP id 00721157ae682-83714123a7fmr56142987b3.33.1786907855860; Sun, 16 Aug 2026 12:17:35 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 00721157ae682-836c17784f2sm38580437b3.32.2026.08.16.12.17.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Aug 2026 12:17:34 -0700 (PDT) From: Chao Shi To: kbusch@kernel.org Cc: hch@lst.de, sagi@grimberg.me, axboe@kernel.dk, joshi.k@samsung.com, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2] nvme: skip the zoned limits update if the zone info query failed Date: Sun, 16 Aug 2026 15:17:29 -0400 Message-ID: <20260816191729.2865523-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 device fails the Identify Namespace (I/O Command Set specific) command, or the Identify Controller command issued by nvme_set_max_append(), the positive status falls through and setup continues with the zero-initialized zone info. nvme_update_zone_info() then marks the queue zoned with chunk_sectors and ns->head->zsze set to zero. blk_validate_zoned_limits() does not check chunk_sectors, so the limits commit succeeds. blk_revalidate_disk_zones() does reject the zero zone size, but by then the limits are live and nothing rolls them back, so I/O keeps being submitted to a zoned queue with a zero zone size and disk_zone_no() 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_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_bh_wbc+0x575/0x740 fs/buffer.c:2824 __block_write_full_folio+0x728/0xdd0 fs/buffer.c:1933 Any device, firmware or NVMe-oF target that fails this one command reaches this. Skip the zoned limits update in that case. The namespace stays registered and usable for admin commands, but the queue is not configured from zone info that was never read. zi.zone_size is an exact indicator: every path that returns a positive status returns before it is assigned, and after that the only failure left is -ENODEV, which the caller already handles. Fixes: c85c9ab926a5 ("nvme: split nvme_update_zone_info") Cc: stable@vger.kernel.org Cc: Weidong Zhu Suggested-by: Keith Busch Found by FuzzNvme. Signed-off-by: Chao Shi --- Changes since v1: - Only skip the zoned limits instead of failing the update, as suggested by Keith. - Gate on zi.zone_size, not zi.max_open_zones, where 0 is legal (reasoning in my reply on v1). - Drop the "malicious device" wording. v1: https://lore.kernel.org/linux-nvme/20260814160954.2839507-1-coshi036@gmail.com/ drivers/nvme/host/core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 453c1f0b2dd0..87e0534cde1c 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2447,8 +2447,13 @@ static int nvme_update_ns_info_block(struct nvme_ns *ns, if (!nvme_update_disk_info(ns, id, nvm, &lim)) capacity = 0; + /* + * A failed zone info query leaves zi zero-initialized. Leave the + * namespace registered so that it can still be used as a device + * handle, but do not configure the zoned limits from it. + */ if (IS_ENABLED(CONFIG_BLK_DEV_ZONED) && - ns->head->ids.csi == NVME_CSI_ZNS) + ns->head->ids.csi == NVME_CSI_ZNS && zi.zone_size) nvme_update_zone_info(ns, &lim, &zi); if ((ns->ctrl->vwc & NVME_CTRL_VWC_PRESENT) && !info->no_vwc) -- 2.43.0