From nobody Fri Apr 17 07:44:19 2026 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 1004531578E for ; Sun, 22 Feb 2026 16:42:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771778560; cv=none; b=sKcHMWhu8h6j0zH1gguopNuasFL/HWtUvIMIRJC2HkAsYJub34ZL0SQE47Ckp1X29H+uBbpItfO676GhA0AVqjS5BK8eUrGPYnXxUO7jBpqgk7XG/VT+tFUFcs1wA01o1NiJ4QfxoMg8QLojlXIgZeMbgtgFWAW9I6tovSOcEBM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771778560; c=relaxed/simple; bh=0KGphQ7xcMJ8IUYPEkuskaHKRIQPpbw45tJn8Lj9Z5M=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=N7zi+Q4hAsJLVBfdQKrSZnWME7VTu7yR4vwb2/ZUY8QZi8kAp9dUUi4/HKk9LEYmOev8pZ2Ip/plVXl+TjjJNLiYywio/faP5nRuhOgfJySSngj+7SsdY/iBHAAXCWySv8oOWfql7TmjM+H/5OdyMdnTukPfyaHKL4nygwl0Nrg= 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=kwMvIvkZ; arc=none smtp.client-ip=209.85.221.42 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="kwMvIvkZ" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-436263e31abso3308952f8f.1 for ; Sun, 22 Feb 2026 08:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771778557; x=1772383357; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=xnUWT/ep+SOYf+xBTNsETmyWIbo2FuZKysNs+dxjANM=; b=kwMvIvkZNyxiOoNrE0anGVsseO0m0fJ22sNlII+Padw+c73u1lCyDe1IiYTBRNRFGl UWoljBaD32lKUJjZhpkEpeNYTETV0Y2jtSkvlmC4Kum2u//+W0Q43pmnPherRddnwduo 4TdnVCbnmcXSGWJUvaRDSTz1OFUpcS+ofuPoNW3z7VZRZp3WvT4FQ1OJ/IEmfP2IoBon 3+74oEGFKtDRzo4XJa0GCrNPaOKFBl4jhIZNqLsoUKep3zweV6FefwKkbwtG9Nuw8hfB heWv2k1iJZ8EL84gL5bcEuerGNXHeGsoAf/pvvFFtxsORUpK7AWhUof0Q0AswC8MmFNO RAoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771778557; x=1772383357; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xnUWT/ep+SOYf+xBTNsETmyWIbo2FuZKysNs+dxjANM=; b=ZuQ1GYOqKeO3cAGAC83/tqjfgEi6Am0qSx+zS+xAb7z0PnwJu8cTSG82jpMiKnvCXo t1lmK+hhv3jTZeamQZGz/1t4st6vyw+umSpnEGLD+wCq3cqQr2ZumHlg63lSJcGryS+J GBQLhc7WeQNI62vj3shpkyfzWY3aPXn9VIiNS2t72iVvhXX+bNedseZ2pdwHnYSEOBTQ 4agVKgp43UUEC74rnXLMEk/Q8hJ2+vLMtoYFnQNqTi5RHjpkvE6is+JMzEI26fnjQLCb SiTNC7waGNj5AUGeU1NLSfo0gplQTsoyd8NUR4mF/+ZnywpaU/Li93ADABEzzByfeqzd Qa6w== X-Gm-Message-State: AOJu0YxMcN2r10kD7ZzB4PhfoTRhPMmrt78fRSUj8ykiX5ySt3asy0Hi eFQvh/rdutBlYQhaOfl3f5yX0MW/dpKhscCA0QHVKbNRAHuC5Qmb/5g22MYaiA== X-Gm-Gg: AZuq6aJP1a8afY2YbPsaKhld2UeR5IMgtfViGkkHITfLegvNbIgpI/eY9cKwUkVD4Gt 0TVuuS97/VYdn2Vv0dbYoghvr3tQtRQyQ3SFnK+F5apMvXvq35To+Ts+dxTgXyYVhYapD3ZBdpy /WsAtgNAJCQssT0ivu5bmjrGc+kB3Byfx4npkFVSBSMILiZHTto5MDm3RQWy6agLLSsdMhyyDBv a6pZnPd7NM1k56t9WvXQjltW1+uo0sc3p3cU+lctJpikXYF7RRo31cQvglW8jR60yHkBShvGp2d ARsonjSGgG/74P1TmcCdyM9wXWvKgtL6HTmGQ0cUB5qr1LLz0kJe8hDG1LKXEAqN32Yy23OnXeG nA15aU1EqkgEqP4h6Fz+DrOTlqNo64ODISF3n+XaSq10WHsMhawVu92DCz6zeVVdhRUlhDgtU2D v32qSZewB0AdoEzjHMKYmkpu1XDG3xmd8vRxMP6A== X-Received: by 2002:a05:6000:25c8:b0:436:3155:86da with SMTP id ffacd0b85a97d-4396f17b307mr11235352f8f.27.1771778556878; Sun, 22 Feb 2026 08:42:36 -0800 (PST) Received: from [192.168.178.22] ([2001:9e8:7a46:6d00:6605:d8ba:3d33:d7af]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43970c08b9csm14635059f8f.16.2026.02.22.08.42.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Feb 2026 08:42:36 -0800 (PST) From: Felix Busch Date: Sun, 22 Feb 2026 17:41:46 +0100 Subject: [PATCH] Added special upper bound check for the logical block address in mmc_ioctl_cdrom_read_data() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260222-cdrom-additional-lba-check-v1-1-5f5e9f0c0fa4@gmail.com> X-B4-Tracking: v=1; b=H4sIAAAAAAAC/x3MQQqEMAxA0atI1hOoAaXOVWQWNYkadFRaEUG8u 8Xlg8+/IGk0TfAtLoh6WLJ1ySg/BfAYlkHRJBvIUe2ICFni+scgYntOw4xzF5BH5QmJvZfSV00 jDvJgi9rb+c7b330/zIMc62wAAAA= X-Change-ID: 20260222-cdrom-additional-lba-check-2c88d18599d0 To: Phillip Potter Cc: linux-kernel@vger.kernel.org, Felix Busch X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1771778517; l=2746; i=felixbusch470@gmail.com; s=20260222; h=from:subject:message-id; bh=0KGphQ7xcMJ8IUYPEkuskaHKRIQPpbw45tJn8Lj9Z5M=; b=+giQ7COlithyZOOXmNJ9imszvJfkY6J8Y6a+mnteVzyfdeaYem11Yjz0ZlHzZgxVrew7Kj3Xc L+zImcrPevWAyI4M2tljbn5hwAYVODC0csk3gsucEc/vgrSVewPMmCM X-Developer-Key: i=felixbusch470@gmail.com; a=ed25519; pk=N5a9fIGjJ0cuci6A25xmqFbNCEDZ5fpG5HW3EhAZpzk= Signed-off-by: Felix Busch --- This patch contains an extra check on the comment=20 for an upper bound check for the logical block address in the=20 function mmc_ioctl_cdrom_read_data().=20 This web page:=20 http://www.o3one.org/hwdocs/cdrom_formats/scsi_programming.htm=20 states that: "Logical adressing of CD-ROM information may use any logical block length. When the specified logical block length is an exact divisor or integral multiple of the selected number=20 of bytes per CD-ROM sector, the device shall map (one to one) the bytes transferred from CD-ROM sectors to the bytes of logical=20 blocks. For instance, if 2048 bytes are transferred from each=20 CD-ROM sector,.., and the logical block length is 512 bytes, then each CD-ROM sector shall map to exactly four logical blocks." If the number of sectors on the CD drive is a multiple of the block size, then, as I understand, it should be possible to perform a=20 simple check on the logical block address in this case. If the logical block address (lba value) is greater than (logical_blocks-1) * blocksize, then it should not be possible=20 to read the next block, because if the lba value is greater than this value, then it might try to read a full next block that=20 does not exist. Please let me know what you think. Thank you very much. --- drivers/cdrom/cdrom.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c index 31ba1f8c1f78..0149813ef903 100644 --- a/drivers/cdrom/cdrom.c +++ b/drivers/cdrom/cdrom.c @@ -2927,6 +2927,7 @@ static noinline int mmc_ioctl_cdrom_read_data(struct = cdrom_device_info *cdi, struct scsi_sense_hdr sshdr; struct cdrom_msf msf; int blocksize =3D 0, format =3D 0, lba; + unsigned int cd_nr_sectors; int ret; =20 switch (cmd) { @@ -2945,9 +2946,19 @@ static noinline int mmc_ioctl_cdrom_read_data(struct= cdrom_device_info *cdi, return -EFAULT; lba =3D msf_to_lba(msf.cdmsf_min0, msf.cdmsf_sec0, msf.cdmsf_frame0); /* FIXME: we need upper bound checking, too!! */ + /* Lower bound check for logical block address. */ if (lba < 0) return -EINVAL; =20 + cd_nr_sectors =3D cdi->disk->part0->bd_nr_sectors; + /* A special case upper bound check. */ + if (cd_nr_sectors % blocksize =3D=3D 0) { + unsigned int logical_blocks =3D cd_nr_sectors / blocksize; + + if (lba > blocksize * (logical_blocks - 1)) + return -EINVAL; + } + cgc->buffer =3D kzalloc(blocksize, GFP_KERNEL); if (cgc->buffer =3D=3D NULL) return -ENOMEM; --- base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b change-id: 20260222-cdrom-additional-lba-check-2c88d18599d0 Best regards, --=20 Felix Busch