Re: [PATCH] cdrom: bound the device-supplied offset in cdrom_mrw_set_lba_space

Re: [PATCH] cdrom: bound the device-supplied offset in cdrom_mrw_set_lba_space

[Phillip Potter]

On Thu, Oct 22, 2026 at 11:19:55AM -0700, Jay Vadayath wrote:
> cdrom_mrw_set_lba_space() issues a MODE SENSE(10) into a 16-byte stack
> buffer (char buffer[16]), then takes offset = be16_to_cpu(mph->desc_length)
> straight from reply bytes 6..7 and does buffer[offset + 3] = space. The
> desc_length field is fully device-controlled (0..65535) and nothing
> checks that offset + 3 lies within the buffer, nor that size (derived
> from mode_data_length) fits. A drive that returns desc_length = 24 turns
> the assignment into buffer[27] = space, a one-byte write 12 bytes past
> the end of the stack buffer.
> 
> This runs when an MRW-writable CD-ROM is opened O_RDWR, so a malicious or
> buggy USB/ATAPI drive (or an emulated one) is enough: no privilege beyond
> being able to open /dev/sr0 for writing on an attacker-supplied device.
> The sink lives in the CD-ROM core, so it affects every cdrom driver
> (sr, ide-cd, pcd, gdrom).
> 
>   BUG: KASAN: stack-out-of-bounds in cdrom_mrw_set_lba_space.constprop.0+0x25c/0x260
>   Write of size 1 at addr ffff88800639f6db by task poc/133
>   Call Trace:
>    dump_stack_lvl+0x64/0x80
>    print_report+0xd0/0x630
>    kasan_report+0xe5/0x120
>    cdrom_mrw_set_lba_space.constprop.0+0x25c/0x260
>    cdrom_open+0x1169/0x2080
>    sr_block_open+0x9e/0x140
>    blkdev_get_whole+0x8c/0x200
>    bdev_open+0x214/0xc40
>    blkdev_open+0x1f8/0x370
>    do_dentry_open+0x408/0x1290
>    path_openat+0xb2f/0x2210
>    do_sys_openat2+0x126/0x170
>    ...
> 
> Both desc_length (offset) and mode_data_length (size) come straight from
> the device reply, so reject anything that would not fit in buffer:
> offset + 3 >= sizeof(buffer) or size > sizeof(buffer) returns -EIO before
> the write. The sibling cdrom_mode_select consumer of size is covered by
> the same guard.
> 
> This bug was discovered by Artiphishell's vTriage pipeline, which
> generated an emulated raw-gadget USB BOT CD-ROM (INQUIRY TYPE_ROM
> advertising MRW-write) plus an open(/dev/sr0, O_RDWR) client that drives
> the capability-probe chain (page 0x2a -> GET CONFIGURATION CDF_MRW ->
> MODE SENSE page 0x03 with desc_length = 24) and reliably triggers the
> KASAN report on an unpatched kernel. The fix below was drafted with the
> Claude coding assistant; a userspace reproducer is available on request.
> 
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Jay Vadayath <jay@artiphishell.com>
> ---
>  drivers/cdrom/cdrom.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
> index 4f1fd389260f..5e910d79045f 100644
> --- a/drivers/cdrom/cdrom.c
> +++ b/drivers/cdrom/cdrom.c
> @@ -571,6 +571,10 @@ static int cdrom_mrw_set_lba_space(struct cdrom_device_info *cdi, int space)
>  	offset = be16_to_cpu(mph->desc_length);
>  	size = be16_to_cpu(mph->mode_data_length) + 2;
>  
> +	/* Both fields are device-supplied; reject values that overflow buffer[]. */
> +	if (offset + 3 >= (int)sizeof(buffer) || size > (int)sizeof(buffer))
> +		return -EIO;
> +
>  	buffer[offset + 3] = space;
>  	cgc.buflen = size;
>  
> -- 
> 2.51.2
>

Hi Jay,

Finally got around to looking at this properly, sorry - been very busy
and life stuff happening too. The fix looks decent as far as I can see.
Can I ask a few things though please:

(1) Please drop the Assisted-by tag.
(2) Please remove reference to Claude itself, and mention just "LLM
    assistance" or such like if you want to (in the description).
(3) Likewise, please remove or substantially reduce the final paragraph.
    How the bug was found is (in my view at least) not relevant to the
    fix, and (perhaps unintentionally) could also read as an
    advertisement. The relevant information to the mechanism the patch
    guards against is all contained in your earlier paragraphs anyway.
(4) Given your inclusion of a call trace anyway, probably worth
    including a Fixes: tag. This may well just be 1da177e4c3f4 in this
    case, but it's a good way of signifying this is suitable for
    backporting.

Hope that's ok? Based on how the patch looks to me, I'm happy to take it
though provided the above is addressed and no other problems are
discovered during runtime testing.

Regards,
Phil

Re: [PATCH] cdrom: bound the device-supplied offset in cdrom_mrw_set_lba_space

[Jay Vadayath]

Hi Phillip,

Thank you for your response and for taking a look at this.
I am happy to make the changes you requested.
However, I wanted to clarify if you would like me to start a new email
thread with the updated format ?

Or was the idea to just follow up on this thread and repost the same
email with the updated format ?

Please let me know how you would like to proceed.

Thank you.


On Tue, Nov 10, 2026 at 2:47 PM Phillip Potter <phil@philpotter.co.uk> wrote:
>
> On Thu, Oct 22, 2026 at 11:19:55AM -0700, Jay Vadayath wrote:
> > cdrom_mrw_set_lba_space() issues a MODE SENSE(10) into a 16-byte stack
> > buffer (char buffer[16]), then takes offset = be16_to_cpu(mph->desc_length)
> > straight from reply bytes 6..7 and does buffer[offset + 3] = space. The
> > desc_length field is fully device-controlled (0..65535) and nothing
> > checks that offset + 3 lies within the buffer, nor that size (derived
> > from mode_data_length) fits. A drive that returns desc_length = 24 turns
> > the assignment into buffer[27] = space, a one-byte write 12 bytes past
> > the end of the stack buffer.
> >
> > This runs when an MRW-writable CD-ROM is opened O_RDWR, so a malicious or
> > buggy USB/ATAPI drive (or an emulated one) is enough: no privilege beyond
> > being able to open /dev/sr0 for writing on an attacker-supplied device.
> > The sink lives in the CD-ROM core, so it affects every cdrom driver
> > (sr, ide-cd, pcd, gdrom).
> >
> >   BUG: KASAN: stack-out-of-bounds in cdrom_mrw_set_lba_space.constprop.0+0x25c/0x260
> >   Write of size 1 at addr ffff88800639f6db by task poc/133
> >   Call Trace:
> >    dump_stack_lvl+0x64/0x80
> >    print_report+0xd0/0x630
> >    kasan_report+0xe5/0x120
> >    cdrom_mrw_set_lba_space.constprop.0+0x25c/0x260
> >    cdrom_open+0x1169/0x2080
> >    sr_block_open+0x9e/0x140
> >    blkdev_get_whole+0x8c/0x200
> >    bdev_open+0x214/0xc40
> >    blkdev_open+0x1f8/0x370
> >    do_dentry_open+0x408/0x1290
> >    path_openat+0xb2f/0x2210
> >    do_sys_openat2+0x126/0x170
> >    ...
> >
> > Both desc_length (offset) and mode_data_length (size) come straight from
> > the device reply, so reject anything that would not fit in buffer:
> > offset + 3 >= sizeof(buffer) or size > sizeof(buffer) returns -EIO before
> > the write. The sibling cdrom_mode_select consumer of size is covered by
> > the same guard.
> >
> > This bug was discovered by Artiphishell's vTriage pipeline, which
> > generated an emulated raw-gadget USB BOT CD-ROM (INQUIRY TYPE_ROM
> > advertising MRW-write) plus an open(/dev/sr0, O_RDWR) client that drives
> > the capability-probe chain (page 0x2a -> GET CONFIGURATION CDF_MRW ->
> > MODE SENSE page 0x03 with desc_length = 24) and reliably triggers the
> > KASAN report on an unpatched kernel. The fix below was drafted with the
> > Claude coding assistant; a userspace reproducer is available on request.
> >
> > Assisted-by: Claude:claude-opus-4-8
> > Signed-off-by: Jay Vadayath <jay@artiphishell.com>
> > ---
> >  drivers/cdrom/cdrom.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
> > index 4f1fd389260f..5e910d79045f 100644
> > --- a/drivers/cdrom/cdrom.c
> > +++ b/drivers/cdrom/cdrom.c
> > @@ -571,6 +571,10 @@ static int cdrom_mrw_set_lba_space(struct cdrom_device_info *cdi, int space)
> >       offset = be16_to_cpu(mph->desc_length);
> >       size = be16_to_cpu(mph->mode_data_length) + 2;
> >
> > +     /* Both fields are device-supplied; reject values that overflow buffer[]. */
> > +     if (offset + 3 >= (int)sizeof(buffer) || size > (int)sizeof(buffer))
> > +             return -EIO;
> > +
> >       buffer[offset + 3] = space;
> >       cgc.buflen = size;
> >
> > --
> > 2.51.2
> >
>
> Hi Jay,
>
> Finally got around to looking at this properly, sorry - been very busy
> and life stuff happening too. The fix looks decent as far as I can see.
> Can I ask a few things though please:
>
> (1) Please drop the Assisted-by tag.
> (2) Please remove reference to Claude itself, and mention just "LLM
>     assistance" or such like if you want to (in the description).
> (3) Likewise, please remove or substantially reduce the final paragraph.
>     How the bug was found is (in my view at least) not relevant to the
>     fix, and (perhaps unintentionally) could also read as an
>     advertisement. The relevant information to the mechanism the patch
>     guards against is all contained in your earlier paragraphs anyway.
> (4) Given your inclusion of a call trace anyway, probably worth
>     including a Fixes: tag. This may well just be 1da177e4c3f4 in this
>     case, but it's a good way of signifying this is suitable for
>     backporting.
>
> Hope that's ok? Based on how the patch looks to me, I'm happy to take it
> though provided the above is addressed and no other problems are
> discovered during runtime testing.
>
> Regards,
> Phil



-- 

Regards
Jay Vadayath, Ph.D.  | Co-founder
Artiphishell

Re: [PATCH] cdrom: bound the device-supplied offset in cdrom_mrw_set_lba_space

[Phillip Potter]

On Tue, Nov 10, 2026 at 03:08:05PM -0700, Jay Vadayath wrote:
> Hi Phillip,
> 
> Thank you for your response and for taking a look at this.
> I am happy to make the changes you requested.
> However, I wanted to clarify if you would like me to start a new email
> thread with the updated format ?
> 
> Or was the idea to just follow up on this thread and repost the same
> email with the updated format ?
> 
> Please let me know how you would like to proceed.
> 
> Thank you.
> 
>

Hi Jay,

So generally, I would submit a new patch, with the subject of:
[PATCH v2] cdrom: bound the device-supplied offset in cdrom_mrw_set_lba_space

And in that patch, mention the changes after the ---, i.e.
Signed-off-by: ...
---
Changes since v1: Updated commit message


Then include the rest of the patch as-is. Please run the completed patch
through scripts/checkpatch.pl as well, and make sure there are no
warnings.

Few more things:
- I seem to be getting duplicate e-mails from you, one in plain text and
  one not. Please send only plain text to the mailing lists.
- Please put your reply underneath the original e-mail/portion of the
  e-mail to which you're responding. Makes it easier to follow then and
  is standard for kernel patch threads/commentaries etc.

I hope that helps.

Regards,
Phil Potter