From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 AEBD12749CF for ; Fri, 27 Feb 2026 18:31:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772217082; cv=none; b=nFxscF+U1BrqO1fZywA6+BUkWHmHRIZyoaschWJIQkhSe3Ia9fQGo2lnSOpFdIfCx4BUNcAHE4drjyixWVOHvSy09tKGcIb/4P9PItK7kd/wUE1+Q8UkAjhAO+wnD80ExO4pzXaQgbMBAx9oqvih9gh7F7qZkR6Ejh6AqNokqyc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772217082; c=relaxed/simple; bh=v3RoMmuMFvHltC9qo6TW7O4Fmgki8POnXCHjCOxjQUE=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=BVqwH6nYVfXC0LYDr1uhRKO2lCD73NgX2hB5h8NitzMFQg5OQlwbHqj97JTAToHM8lllpjnqj11kl9h7quMlUbcoMT2ocvmFXQuvZTpHfHqZMttm6VFosJ2b1JhV+JUXk951zAt/+6aYtYdSqh6DisW4/ARS5qGPIDMicrDId0M= 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=Zf/OtbYW; arc=none smtp.client-ip=209.85.128.54 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="Zf/OtbYW" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4833115090dso23723905e9.3 for ; Fri, 27 Feb 2026 10:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772217079; x=1772821879; darn=vger.kernel.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=//Qf3i18W4b1UKgZ8U7UH+XNML6GTnCQ/U8eSEADCbw=; b=Zf/OtbYW3WbrMLBFLU7hK23cNKDohgrAc7d65BqGUUMtV+262x4vHnZ6DGtvTSqK0u oKzrP0Yz8rCraaFyx1/FlvtkskmZgdT4X224kkpFhcT1Qq2ZkiVyzecOhgTIYTWg0B5K zaejJw7MUCBlRnPfeFR6Igo0a5/06Ie3ZHstlMOmoum3ybwCsUfXi0QwtIl+8Gg9iok/ deEtZjuuz7QGygr0eUndWf1eJLPMkJLBAO4MqkQKNajPkDp9Ql3TiClqBnO4nfwdjYwx R+zjGBPf9G6AfV1UG/D0wFTAFDewZ69N/T7wpQSmE8JaxFsq3zdbMAC5jbe/6aELdzmb 1h7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772217079; x=1772821879; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=//Qf3i18W4b1UKgZ8U7UH+XNML6GTnCQ/U8eSEADCbw=; b=B90zhaEYNe+p/i3pzTmiEhVCahbkxi5SjIJPeEB+u+hv6KvySngVtuA54KgaeLym8B 6WXs+OhUAFPHmFk9DnbQJTFGZC2wlONWo7xCAp1aF8Zgx9pAaVszVaHI3RVSmaBOtvXi wwPu8oTh8u+JfCkXL+vg2xs1LGrGphCRr+SDLFWMuHpOsytv5iODQ0GdjYKduWp6yLrb uyeGqI32aS6RLTp7rgE7C62LSSoGiea11FAFQ2YsjpkgeznG+W9DShkjclGgJDcawvla Vj128jSHlmfCHCk+rYvevX3BF4E7tlwuzG+UCuTai5+EOlsjujdPzoAGmQvmz06CRgZI u4RA== X-Gm-Message-State: AOJu0Yzd/W2WC8EYf2AO69CkTSN2kLYQdHg8nrf2rMr2UVLztN3hfGhf ftQ2HDa+tPtuSpXwCCAY2tSYeFbdDpjXKgHcOrmHB9SkZzXf+YzI0vkLguuIsg== X-Gm-Gg: ATEYQzzW5SIGfhHhIT53W0I1eLU/jTUyIrqht9ROilKN0sFFrnYoX/778VOpHZTuLzU 4YWVj14+n81axUq3QZKM5v7fc8TvwU3a82mF3NNKER4mn0rdfpfvuZG0ipmKKg9FpWtftf6X24p c2Chtnv1ObtutSgMLXEqzWNP52TW7tYFmvLA7DfzoPlgGUNAshAlEKFPugrq/FHNGld07/Uli2d CHCBFKKGTM+SYn/X/bPUqoWxiHbua0Gtu3HWvT8BFF96Z1j9Suxw+p9Ad6AOsVEU2kJZbYGpkrd fK+uxMTKxHjeYD0Qs0xbaNTA4NDEmrOQpBHAXDbWZx5XnWT8eX/8ZJwDc+zCh9MS4pCyVd8HPYQ SlSSTBSr9KRzFTTbFTfzzA9Jz4QgjT+UcT8Uoerk1P5wgq2Gpcq/wbWcH6okINMXnJxKHOENneV yiagIfauTz2oMOqyXVCiGQ5M0D07EHQpe7ys1jzrY= X-Received: by 2002:a05:600c:3512:b0:480:7162:fa48 with SMTP id 5b1f17b1804b1-483c9bb1fcfmr65680865e9.13.1772217078544; Fri, 27 Feb 2026 10:31:18 -0800 (PST) Received: from localhost ([2001:9e8:7a71:9600:c58d:b923:61c9:c536]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70ed47sm9051552f8f.11.2026.02.27.10.31.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 10:31:18 -0800 (PST) Date: Fri, 27 Feb 2026 19:30:30 +0100 From: Felix Busch To: linux-kernel@vger.kernel.org Subject: Fwd: Re: [PATCH v2 1/2] [PATCH] cdrom: extra upper bound check for logical block address. Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="eh3wobtqsylvajby" Content-Disposition: inline --eh3wobtqsylvajby Content-Type: text/plain; charset=us-ascii Content-Disposition: inline --eh3wobtqsylvajby Content-Type: message/rfc822 Content-Disposition: inline MIME-Version: 1.0 Date: Fri, 27 Feb 2026 18:56:06 +0100 References: <20260224161640.16760-1-felixbusch470@gmail.com> In-Reply-To: Message-ID: Subject: Re: [PATCH v2 1/2] [PATCH] cdrom: extra upper bound check for logical block address. From: Felix Busch To: Phillip Potter Cc: phil@philpotter.co.uk, linux-kernel@vger.kernel.org Content-Type: multipart/alternative; boundary="000000000000f6dbd1064bd1f53b" X-TUID: uaKz4F//Xrhm --000000000000f6dbd1064bd1f53b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, sorry for this confusion. I somehow had in mind while reading this spec that when the capacity of the disk is a multiple of the block size, then the sector size would also be a multiple of the block size, which is of course not true. Then, of course this needs to have a bit more of searching. Regards Felix Am Do., 26. Feb. 2026 um 21:28 Uhr schrieb Phillip Potter < phil@philpotter.co.uk>: > On Tue, Feb 24, 2026 at 05:16:12PM +0100, Felix Busch wrote: > > Hi Phillip, > > > > Thank you for your feedback. I=E2=80=99ve updated everything based on y= our > suggestions and hope > > I=E2=80=99ve covered them all. > > > > It has been built and run and tested in the following: > > > > 1) This has been tested on a real CD-ROM with 700MB capacity, containin= g > 2097151 > > sectors in my case. Since 2097151 is not divisible by a blocksize of > 2048, the if condition is not satisfied. > > > > 2) When using a smaller emulated CD-ROM with QEMU with the same > blocksize, > > the if condition is triggered when having a too big logical block > addresses. For example, this occurs when minutes, > > seconds, and frames are set to UINT8_MAX via an ioctl call. > > > > According to this SCSI-2 spec, chapter 14 on this web page (date > 23.2.2026): > > https://www.staff.uni-mainz.de/tacke/scsi/SCSI2-introduction.html > > > > They are stating: > > " > > Logical addressing 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 > 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 blocks. > > For instance, if 2 048 bytes are transferred from each CD-ROM sector > (specified by the CD-ROM density code value), > > and the logical block length is 512 bytes, then each CD-ROM sector shal= l > map to exactly four logical blocks. > > This International Standard does not define the mapping of logical bloc= k > lengths which do not evenly divide > > or are not exact multiples of the selected number of bytes per CD-ROM > sector. > > " > > > > So, I do refer to this SCSI-2 spec. > > Using this information it's possible to use logical_blocks =3D > cd_nr_sectors / blocksize to get the number of blocks that are be able to > read due to this mapping. > > For now, I decided using this special checking only, due to the given > statement in the SCSI-2 spec. > > > > If lba > blocksize * (logical_blocks - 1), then it should not be > possible to continue reading a full block, because then, as I understand, > > it would "overflow" the region it can read from the disk. > > > > I've seen your V3 - please make sure the relevant mailing list is copied > in when posting patches, as development is ideally done in the open. As > for that and for this version, I'm sorry but I'm still not convinced of > the approach unless I'm missing something. > > You are taking units of two different things and dividing one by the > other. Dividing the number of sectors (2,097,151) by the detected > blocksize (2048 bytes) is not meaningful. The statement in the SCSI-2 > spec simply refers to the difference between CD-ROM sector size in bytes > and the logical block size in bytes. > > Here, you are dividing one thing (number of sectors) by another (block > size). Do you see what I mean? > > Finally, please make sure cover letters of a patch series are labels > PATCH 0. > > Regards, > Phil > --000000000000f6dbd1064bd1f53b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
sorry for this confusion.
I somehow had in mind= while reading this spec that when the capacity of the disk
is a multip= le of the block size, then the sector size would also be a multiple
of t= he block size, which is of course not true. Then, of course this needs tohave a bit more of searching.

Regards
Felix

Am Do., 26. Feb. 2026 um 21:28=C2=A0Uhr schrieb Phillip Potter <phil@philpotter.co.uk>:
=
On Tue, Feb 24, 2026 at 0= 5:16:12PM +0100, Felix Busch wrote:
> Hi Phillip,
>
> Thank you for your feedback. I=E2=80=99ve updated everything based on = your suggestions and hope
> I=E2=80=99ve covered them all.
>
> It has been built and run and tested in the following:
>
> 1) This has been tested on a real CD-ROM with 700MB capacity, containi= ng 2097151
> sectors in my case. Since 2097151 is not divisible by a blocksize of 2= 048, the if condition is not satisfied.
>
> 2) When using a smaller emulated CD-ROM with QEMU with the same blocks= ize,
> the if condition is triggered when having a too big logical block addr= esses. For example, this occurs when minutes,
> seconds, and frames are set to UINT8_MAX via an ioctl call.
>
> According to this SCSI-2 spec, chapter 14 on this web page (date 23.2.= 2026):
> https://www.staff.uni-mainz.de= /tacke/scsi/SCSI2-introduction.html
>
> They are stating:
> "
> Logical addressing of CD-ROM information may use any logical block len= gth. When the specified logical block
> length is an exact divisor or integral multiple of the selected number= of bytes per CD-ROM sector,
> the device shall map (one to one) the bytes transferred from CD-ROM se= ctors to the bytes of logical blocks.
> For instance, if 2 048 bytes are transferred from each CD-ROM sector (= specified by the CD-ROM density code value),
> and the logical block length is 512 bytes, then each CD-ROM sector sha= ll map to exactly four logical blocks.
> This International Standard does not define the mapping of logical blo= ck lengths which do not evenly divide
> or are not exact multiples of the selected number of bytes per CD-ROM = sector.
> "
>
> So, I do refer to this SCSI-2 spec.
> Using this information it's possible to use logical_blocks =3D cd_= nr_sectors / blocksize to get the number of blocks that are be able to read= due to this mapping.
> For now, I decided using this special checking only, due to the given = statement in the SCSI-2 spec.
>
> If lba > blocksize * (logical_blocks - 1), then it should not be po= ssible to continue reading a full block, because then, as I understand,
> it would "overflow" the region it can read from the disk. >

I've seen your V3 - please make sure the relevant mailing list is copie= d
in when posting patches, as development is ideally done in the open. As
for that and for this version, I'm sorry but I'm still not convince= d of
the approach unless I'm missing something.

You are taking units of two different things and dividing one by the
other. Dividing the number of sectors (2,097,151) by the detected
blocksize (2048 bytes) is not meaningful. The statement in the SCSI-2
spec simply refers to the difference between CD-ROM sector size in bytes and the logical block size in bytes.

Here, you are dividing one thing (number of sectors) by another (block
size). Do you see what I mean?

Finally, please make sure cover letters of a patch series are labels
PATCH 0.

Regards,
Phil
--000000000000f6dbd1064bd1f53b-- --eh3wobtqsylvajby--