From nobody Mon Jun 8 05:25:24 2026 Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) (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 85F30299931 for ; Sat, 6 Jun 2026 17:04:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780765460; cv=none; b=FKryIaxBIKCW0gq6Nv0QiNLxi9c5LC+qmKF6HLipluNoM4MVvMCRoKZEZ8MBhZnoaA8PtOoa2J2xz5+6HAfr2FsVDDyZnWSFZwxYKakYdFk6F2r4Qq+8vw6a91DxKzqJtvhLq7pKIA7rULYxYtTaLBTdvrxnoZzQBKq8kPiKdh4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780765460; c=relaxed/simple; bh=q2NQZY+epqVHr2W7oOJcKG76cTiGmU8+/2BHRpz2gI8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Z7dgpPCy60rfmmDEYLKQZAp4kQhWxsKw94Gs22/MOoE3CCdrwhjYQRgK/DZAwboDWBilOTj/b7zk57EMI3p1QI/oMj1t5KH2Qnw+iiQlflLP0ln2V6WKpU4dtBB/l+/0QNIjBPSmyjhMowceFwmlEZqjN2oiebOwYULFYO0uDBc= 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=fHO3P2AQ; arc=none smtp.client-ip=209.85.219.41 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="fHO3P2AQ" Received: by mail-qv1-f41.google.com with SMTP id 6a1803df08f44-8ccdf8d4ac5so33333186d6.1 for ; Sat, 06 Jun 2026 10:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780765458; x=1781370258; 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=ByUZh0lFBgTCiciJpjsG9ZXS068Tz2mmn6cEtLPjSXA=; b=fHO3P2AQWwXQt7pnhvIBf7F4LozVmvF8zHul+47XYUemaHbEReph1mDRFC82mya1wn pH+FXJar6/OtJO/MKnDLafHXxJoYRUkiBmxAMhP3L0QSZUIpTd45i8KzsjwfC1BV9Kmz J2lOrgbo5tCZszqjd0q5Q72z8wTed30ow/sDS7bYb7ZwVXcXieoH67FWPBiEV83dtax6 L9gG4Z/ZnXriIVSeHrdRBOaDW9bxrTnHRT7wohsfNecXMlsAU518zLELmXMHzwdhSNtL LHDMlktxMYZCZ0ajFkEl8mAAhWVf/hCviZHoZak1JV6pfTbmp+O1u2QuV3lmK4L41LeJ yRuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780765458; x=1781370258; 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=ByUZh0lFBgTCiciJpjsG9ZXS068Tz2mmn6cEtLPjSXA=; b=Jzpy4UeR53QrQK9n9n5+AvGnEVPBRfL39yXdw81morJPb62cTaSu0gDg4J3yd7hBg8 nmwe7/UA8F6EmqygMA23WQ+LYkQYGd1D2FN9oU91e5QXym/Hd0IByT026bMxc5fEI/+Y 8fmnkW+M0geCgu2IpK5zF7LeJDRIBjJdbs3V7+uakTBUBEWLk1eP1ccWZiPIxCMRaouG v6F9pHvx9AjSxnxuVod8k6zCaVPieE7c6X4fllGKlw2C0rXuagIkrpihNVftmZXNka8Z ht9Yg899ROxUK40sTQIBjfA6PrZi9Xq+hXsRyEBSbuzV3ChIFmGlYTldCf6YmRkYArTL eXWQ== X-Forwarded-Encrypted: i=1; AFNElJ88xV2QGHQ4IvzDKNIrLl7VqZKiBt8qjbkVdA6hlqfycFfwuxIAXHcR0gHy479NExLkf1AqHkIp0jJV8fw=@vger.kernel.org X-Gm-Message-State: AOJu0YwXmmY7lB7elrY182XQJh0CGGxX2AasZIuorLCrFolrq/b0ktsf FbxqbQUNvNJqVWtRx592aiHM1FYBDCxJMyva13F9ziRTz5PAsDcaWtEM X-Gm-Gg: Acq92OHfrbPkI7IpJ1yJmrZ+/pp1AgshP0j+Z1+I0pw76mvXE1jn3bY7tAnNyhpbTzQ QsCpZhVZCfBj9W+JOcJUho5Xy6kkvf9ldu8mA6f/zlLBZ7bPeofpIcDux4knrO3Ab7bLlYvUBrF +uvKGRQBYfWOtVFL0LmdY2rtrZ9RaLgMIDTNptQG34cLAs+nVFsKYmbEyqOFcaMhwgzf1zRit4n zZnqmB0rA4lkZRdzNeAuFg9wK7mZoXHsPJO5vIn53EBdk68jLK5Gxbh9Ohm3cfEsdZiMZHwE/nQ OKI1YNBRMWViMpt+nkvmB8sD3U10n2FFC2JZ8LQo6TZBOEcqfsbsIHMXULDZa2SHhvzRnGi7Wt9 wtWAsKtA/zzJIfYoo2WigdKkteXVtTh1ZTv2qm+wff3342nAAoFyF2yJS9Q/8A2YYUfJOVwFESp QBEwBdqIy55LKqjbJ6r4W0nSd1X7yDRHuAxIwTra0mIMKlHGbuEhSjtatYKzQOmoiJo2t1OZzMT dedZAEJTfPkenYqfCPWjXH4wigHYRQ= X-Received: by 2002:a0c:f10c:0:b0:8cc:ee52:3e60 with SMTP id 6a1803df08f44-8cee5f99418mr119842996d6.3.1780765458414; Sat, 06 Jun 2026 10:04:18 -0700 (PDT) Received: from server0 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ceccd9fc7dsm112977966d6.5.2026.06.06.10.04.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2026 10:04:17 -0700 (PDT) From: Michael Bommarito To: "Michael S . Tsirkin" , Jason Wang , Stefan Hajnoczi , Jens Axboe Cc: Xuan Zhuo , virtualization@lists.linux.dev, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] virtio-blk: clamp zone report to the report buffer capacity Date: Sat, 6 Jun 2026 13:04:15 -0400 Message-ID: <20260606170415.1523660-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" virtblk_report_zones() trusts the device-reported number of zones when walking the report buffer: nz =3D min_t(u64, virtio64_to_cpu(vblk->vdev, report->nr_zones), nr_zones); ... for (i =3D 0; i < nz && zone_idx < nr_zones; i++) { ret =3D virtblk_parse_zone(vblk, &report->zones[i], ...); The buffer is allocated by virtblk_alloc_report_buffer(), whose size is capped by the queue's max hardware sectors and max segments and can therefore hold fewer descriptors than nr_zones. nz is bounded only by the device-supplied report->nr_zones and the requested nr_zones, never by the buffer's descriptor capacity. At probe time the request count is unbounded (blk_revalidate_disk_zones() calls report_zones() with nr_zones =3D=3D UINT_MAX), so the device-supplied report->nr_zones is the sole gate: a device that reports more zones than fit in the buffer drives the loop to read report->zones[i] past the end of the allocation. A malicious or buggy virtio-blk device that reports an inflated nr_zones triggers this during zone revalidation at probe. KASAN reports a vmalloc-out-of-bounds read in virtblk_report_zones() against the report buffer allocated a few lines earlier. Clamp nz to the number of descriptors that actually fit in the report buffer. Fixes: 95bfec41bd3d ("virtio-blk: add support for zoned block devices") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito --- drivers/block/virtio_blk.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index b1c9a27fe00f3..d50aaf956d558 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -689,6 +689,14 @@ static int virtblk_report_zones(struct gendisk *disk, = sector_t sector, =20 nz =3D min_t(u64, virtio64_to_cpu(vblk->vdev, report->nr_zones), nr_zones); + /* + * The device-reported nr_zones is untrusted; clamp it to the + * number of descriptors that actually fit in the report buffer + * so a malicious or buggy device cannot drive the parse loop + * past the allocation. + */ + nz =3D min_t(u64, nz, + (buflen - sizeof(*report)) / sizeof(report->zones[0])); if (!nz) break; =20 base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8 --=20 2.53.0