From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) (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 B7D622F7EF2 for ; Fri, 15 May 2026 18:58:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778871541; cv=none; b=U0/tihdWAh2YmR/q79iFLipIFRKTBZap+NDWCgppEADAg7q1SsAGpvLzVbFEZGXjgpLfwQERy0piPT4IA9sdr1oaHG75g1LgArsyESA4EBRtDRKdg6MgEHlcq4F+CZty6X7OFNjVwO1xl1WRFBlhNS/vCBaTbRrevFayO14d6OE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778871541; c=relaxed/simple; bh=WHT6f6LHdNMWDgFSCModqI3rgTA8iGG+Bgw8beFIwB4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=njaR97/OZ3LLg/XL33j5psb0cKkWgdcNaW+9TiSlVz7yonx0YES4EWBClbufXmZ2AWmzzj2sTnkZfGJn9bTqKzYpUYPjBMp10eSCymvXQSOoEaJOTeWw38wRvEimZ2Rrc/mK6jyHJniJ26gTbB91amH3eAUWDWPXH+r34OSGNac= 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=MPm2bpQr; arc=none smtp.client-ip=209.85.222.51 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="MPm2bpQr" Received: by mail-ua1-f51.google.com with SMTP id a1e0cc1a2514c-95f61c1ace0so32158241.2 for ; Fri, 15 May 2026 11:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778871539; x=1779476339; 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; bh=QSi0U5scWG8acBST7RqnHrwKWntKtZB1nMVqsvrLh3w=; b=MPm2bpQrutWTr0LRh9pFiFFTNKMsqpp69knSgRgTygpobdOyKf0WogMagsm0bwuPb2 Qgh7J0Z4In/rfYFkZQlf8es0dmf81ZBLK+v6J+OdouRM53dPRQpj4hnzFTHypJa2dkyw OPSCQxcZsYswVvGPKGU/yCjUCvHR3s9TW9NgaPyCd4vEwn/hGUq5q7eHTcnpIVQy6ul7 Dg8U344Mzn+mvDLtm9gEfKxW/SzAlRtgEq2Hbhg9eGJdsaMPr/wmjfW3Wbv8KSLt/4pK nLtO7Cjzd4zfekvcde47Ufaj3mAX8Aw5hPM6EduNhKTeNahUDtZW9B4SDvt4mFr/3PtK QEOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778871539; x=1779476339; 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; bh=QSi0U5scWG8acBST7RqnHrwKWntKtZB1nMVqsvrLh3w=; b=WYFWhIOgQs4rXXO30ZVK8s1PvkMHJw+2rsKpSnv2w/5gsfnYQsG4jcOqsHrJmdYKw7 PxplZq0JZHIEw8wYEGh8R39WVwqapFJTBX9eGFxMWVLBxU0Qpen4F+4rzrMUUL8UO5FT lXvucVB0r1FkT6Q9jchyIKDLbt22IyXO/znUP0Px4d+rC4pndeX0o3g7K7eCmdH4MtmP ++8DdTjuag5/wiGlwTjf9uDWrBYZ0ZXzACDgsViuYeyGyMsPlnfNy0jGdJbP3FrjDk8m y+MNn3PCAyXSTstS8CXXyDSIB6jpYRSBPCC59ZSyOm0BGK49CNqUyfNWkU8MTiHRVDcj onKw== X-Forwarded-Encrypted: i=1; AFNElJ8ROHh0F3Ya5yUL9AefAqUqkjVSyswUSUIhtsc0MOX120Y3laCXCsz42OTaU1ujMnL5RKwn2iA4frs+3VE=@vger.kernel.org X-Gm-Message-State: AOJu0Yy9YcsdYgdapt8okXVg7JExDp1PvKdfjD3set2ccFzZcDt22sq4 cdjXCV5/Sdfd8u8b6O0iqzKHJGLwMJ/loAKu1T/gMYpmVcCIf59ExuRt X-Gm-Gg: Acq92OFdY2BkTOiS+WwvOopiufmNOTllV2HVlzWkuWCral9YcMIfzIGo8nCUtdp7hN/ nqW01d0waWdDIcHMvmjPlUpays0TtHENiikZYjldNJBjqJWlnnFPIraF5S/0Lrlv8abKRuIC1hV 52F9wbFkVW+VQx7/6WOgbnuY6MPC4xU2QtniiCCbpuddFhDyw1yaz6qTrnab6vzwn5AZG7Q0gKH VhTwPHj3miU1KA/PxzosL+04z4bkcjhr+U8rWMllkmTtrWS6WM/O/tWxdip8fPDVUSG5fvgYuUw SMaGqGfNxTumjp0HRXxPzdZBf10HEairk7baUgjdMb2oopuZgRH2Y8RJtpCI+MVLnnt1emCyTBf XiM72feEgEpWg6dYO+Lzp5u+4LhHiI29dV32th9LQCuilpUQusi+9dhZmV2EEXjzb8cSp3896dx RxPAsSD4BE3VzXyi833YMKk6PyjTsq4GEDY1FLkQYngfGgFb4gKNTJ X-Received: by 2002:a05:6102:3048:b0:604:f029:224c with SMTP id ada2fe7eead31-63a3d3257b8mr3530733137.8.1778871538584; Fri, 15 May 2026 11:58:58 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-95fc2cc387esm1588052241.4.2026.05.15.11.58.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2026 11:58:58 -0700 (PDT) From: Chao Shi To: Keith Busch , Jens Axboe , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Christoph Hellwig , Sagi Grimberg , Daniel Wagner , Hannes Reinecke , Maurizio Lombardi , Chao Shi , Sungwoo Kim , Dave Tian , Weidong Zhu Subject: [PATCH v3] nvme: core: reject invalid LBA data size from Identify Namespace Date: Fri, 15 May 2026 14:58:53 -0400 Message-ID: <20260515185853.2761456-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_update_ns_info_block() trusts id->lbaf[lbaf].ds from the controller and assigns it directly to ns->head->lba_shift without bounds checking. nvme_lba_to_sect() then does: return lba << (head->lba_shift - SECTOR_SHIFT); When called with lba = le64_to_cpu(id->nsze) to compute the device capacity, an attacker-controlled controller can choose ds < 9 or a combination of (ds, nsze) that makes the left shift overflow sector_t. The former is a C undefined behaviour that UBSAN reports as a BUG; the latter silently yields a bogus capacity that the block layer then trusts for bounds checking. Validate ds against SECTOR_SHIFT and use check_shl_overflow() to compute capacity so that any (ds, nsze) combination that would overflow sector_t is rejected. The namespace is skipped with -ENODEV instead of crashing the kernel. This is reachable by a malicious NVMe device, a buggy firmware, or an attacker-controlled NVMe-oF target. The check is performed before queue_limits_start_update() and blk_mq_freeze_queue(), so the error path is a plain `goto out` with no cleanup needed. Stack trace (UBSAN, ds < 9 variant): RIP: nvme_lba_to_sect drivers/nvme/host/nvme.h:699 [inline] RIP: nvme_update_ns_info_block.cold+0x5/0x7 Call Trace: nvme_update_ns_info+0x175/0xd90 drivers/nvme/host/core.c:2467 nvme_validate_ns drivers/nvme/host/core.c:4299 [inline] nvme_scan_ns drivers/nvme/host/core.c:4350 nvme_scan_ns_async+0xa5/0xe0 drivers/nvme/host/core.c:4383 async_run_entry_fn process_one_work worker_thread kthread Found by Syzkaller. Acked-by: Sungwoo Kim Acked-by: Dave Tian Acked-by: Weidong Zhu Signed-off-by: Chao Shi --- Changes since v2: - Hoist the validation above queue_limits_start_update() and blk_mq_freeze_queue(); error path is now a plain `goto out`. - Merge the ds == 0 case into the general invalid check. v1: https://lore.kernel.org/linux-nvme/20260418042835.420281-1-coshi036@gmail.com/ v2: https://lore.kernel.org/linux-nvme/20260420231116.748204-2-coshi036@gmail.com/ drivers/nvme/host/core.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 1e33af94c24b..12ff562dd142 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2404,12 +2404,22 @@ static int nvme_update_ns_info_block(struct nvme_ns *ns, goto out; } + if (id->lbaf[lbaf].ds < SECTOR_SHIFT || + check_shl_overflow(le64_to_cpu(id->nsze), + id->lbaf[lbaf].ds - SECTOR_SHIFT, + &capacity)) { + dev_warn_once(ns->ctrl->device, + "invalid LBA data size %u, skipping namespace\n", + id->lbaf[lbaf].ds); + ret = -ENODEV; + goto out; + } + lim = queue_limits_start_update(ns->disk->queue); memflags = blk_mq_freeze_queue(ns->disk->queue); ns->head->lba_shift = id->lbaf[lbaf].ds; ns->head->nuse = le64_to_cpu(id->nuse); - capacity = nvme_lba_to_sect(ns->head, le64_to_cpu(id->nsze)); nvme_set_ctrl_limits(ns->ctrl, &lim, false); nvme_configure_metadata(ns->ctrl, ns->head, id, nvm, info); nvme_set_chunk_sectors(ns, id, &lim); -- 2.43.0