public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Phillip Potter <phil@philpotter.co.uk>
To: Felix Busch <felix.busch1@gmx.net>
Cc: James.Bottomley@hansenpartnership.com,
	martin.petersen@oracle.com, phil@philpotter.co.uk,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 1/1] CD-ROM: Additional LBA bound check
Date: Mon, 30 Mar 2026 22:49:15 +0100	[thread overview]
Message-ID: <acrv2_GCdJC5C0qE@equinox> (raw)
In-Reply-To: <20260325074401.6530-1-felix.busch1@gmx.net>

Hi Felix,

Nice to hear from you again, hope you're well. Apologies for me taking a
few days to reply, I've had a a fair amount on at work.

On Wed, Mar 25, 2026 at 08:44:01AM +0100, Felix Busch wrote:
> Upper bound check for the logical block address
> in mmc_ioctl_cdrom_read_data() of the CD-ROM driver.
> This prevents trying to read a block when the LBA is
> greater than the number of available blocks.
> 
> Signed-off-by: Felix Busch <felix.busch1@gmx.net>
> ---
>  drivers/cdrom/cdrom.c |  7 +++++--
>  drivers/scsi/sr.c     | 12 +++++++++++-
>  include/linux/cdrom.h |  2 ++
>  3 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
> index fc049612d6dc..cc0a6c0ae9e7 100644
> --- a/drivers/cdrom/cdrom.c
> +++ b/drivers/cdrom/cdrom.c
> @@ -2926,6 +2926,8 @@ static noinline int mmc_ioctl_cdrom_read_data(struct cdrom_device_info *cdi,
>  {
>  	struct scsi_sense_hdr sshdr;
>  	struct cdrom_msf msf;
> +	const struct cdrom_device_ops *cdo = cdi->ops;
> +	u64 nr_blocks;
>  	int blocksize = 0, format = 0, lba;
>  	int ret;
>  
> @@ -2944,8 +2946,9 @@ static noinline int mmc_ioctl_cdrom_read_data(struct cdrom_device_info *cdi,
>  	if (copy_from_user(&msf, (struct cdrom_msf __user *)arg, sizeof(msf)))
>  		return -EFAULT;
>  	lba = msf_to_lba(msf.cdmsf_min0, msf.cdmsf_sec0, msf.cdmsf_frame0);
> -	/* FIXME: we need upper bound checking, too!! */
> -	if (lba < 0)
> +	nr_blocks = cdo->get_capacity(cdi);

This (as with other function pointers that are part of cdrom_device_ops,
should be checked first to see if it's initialised? (it is for sr.c of course,
but what about others?)

> +	/* Lower and upper bound check for logical block address. */
> +	if ((lba < 0) || (lba > nr_blocks - 1))
>  		return -EINVAL;

The point James makes about the return value now being different (as it
would previously have been an error from the device itself) is a good
one. This is probably the hardest question to answer in terms of which
software may or may not break.

>  
>  	cgc->buffer = kzalloc(blocksize, GFP_KERNEL);
> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
> index 7adb2573f50d..a056c72341c4 100644
> --- a/drivers/scsi/sr.c
> +++ b/drivers/scsi/sr.c
> @@ -120,6 +120,8 @@ static int sr_packet(struct cdrom_device_info *, struct packet_command *);
>  static int sr_read_cdda_bpc(struct cdrom_device_info *cdi, void __user *ubuf,
>  		u32 lba, u32 nr, u8 *last_sense);
>  
> +static u64 sr_get_nr_blocks(struct cdrom_device_info *cdi);
> +
>  static const struct cdrom_device_ops sr_dops = {
>  	.open			= sr_open,
>  	.release	 	= sr_release,
> @@ -134,6 +136,7 @@ static const struct cdrom_device_ops sr_dops = {
>  	.audio_ioctl		= sr_audio_ioctl,
>  	.generic_packet		= sr_packet,
>  	.read_cdda_bpc		= sr_read_cdda_bpc,
> +	.get_capacity		= sr_get_nr_blocks,
>  	.capability		= SR_CAPABILITIES,
>  };
>  
> @@ -142,6 +145,13 @@ static inline struct scsi_cd *scsi_cd(struct gendisk *disk)
>  	return disk->private_data;
>  }
>  
> +static inline u64 sr_get_nr_blocks(struct cdrom_device_info *cdi)
> +{
> +	struct scsi_cd *cd = scsi_cd(cdi->disk);
> +
> +	return cd->capacity;
> +}
> +
>  static int sr_runtime_suspend(struct device *dev)
>  {
>  	struct scsi_cd *cd = dev_get_drvdata(dev);
> @@ -782,7 +792,7 @@ static int get_sectorsize(struct scsi_cd *cd)
>  			sector_size = 2048;
>  			fallthrough;
>  		case 2048:
> -			cd->capacity *= 4;
> +			//cd->capacity *= 4;

This is here for a reason, it should not be commented out. I may not
have worded it clearly in my response to your previous patch, but this
is the kind of thing I was talking about before.

>  			fallthrough;
>  		case 512:
>  			break;
> diff --git a/include/linux/cdrom.h b/include/linux/cdrom.h
> index b907e6c2307d..406e6f4a55bb 100644
> --- a/include/linux/cdrom.h
> +++ b/include/linux/cdrom.h
> @@ -91,6 +91,8 @@ struct cdrom_device_ops {
>  			       struct packet_command *);
>  	int (*read_cdda_bpc)(struct cdrom_device_info *cdi, void __user *ubuf,
>  			       u32 lba, u32 nframes, u8 *last_sense);
> +	/* Get size in blocks */
> +	u64 (*get_capacity)(struct cdrom_device_info *cdi);

I notice we only define an implementation of this for sr.c? At a glance,
it's also possible to trigger this code from the GD-ROM driver, unless
I'm missing something?

>  /* driver specifications */
>  	const int capability;   /* capability flags */
>  };
> -- 
> 2.53.0
>

I take your point about avoiding the read entirely, and I see what you
mean there. That said, I'm not sure this is necessary given the
potential dangers.

Regards,
Phil

      parent reply	other threads:[~2026-03-30 21:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-25  6:53 [PATCH 0/1] *** CD-ROM: LBA bound check in mmc_ioctl_cdrom_read_data *** Felix Busch
2026-03-25  7:44 ` [PATCH 1/1] CD-ROM: Additional LBA bound check Felix Busch
2026-03-25 12:55   ` James Bottomley
2026-03-26 18:11     ` Felix Busch
2026-03-30 21:49   ` Phillip Potter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acrv2_GCdJC5C0qE@equinox \
    --to=phil@philpotter.co.uk \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=felix.busch1@gmx.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox