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

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

[Jay Vadayath]

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

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,

Thanks for your patch. Won't be able to review straight away as I'm
travelling early tomorrow and busy most of the day. Please can you
provide the userspace reproducer code to me too in the meantime,
thanks.

Regards,
Phil

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

[Jay Vadayath]

[-- Attachment #1: Type: text/plain, Size: 3986 bytes --]

Hi Phillip,

Thank you for looking into this.
I've attached the reproducer bundle with this email.

SHA-256 (cdrom-mrw-poc.tar.gz):
74d42cf0c7974233fada470f2eec2dbb1c59719414a2e54619a09f52d55ca015

Please let me know if you have any questions.

Thanks


On Fri, Oct 23, 2026 at 2:19 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,
>
> Thanks for your patch. Won't be able to review straight away as I'm
> travelling early tomorrow and busy most of the day. Please can you
> provide the userspace reproducer code to me too in the meantime,
> thanks.
>
> Regards,
> Phil



-- 
Regards
Jay Vadayath

[-- Attachment #2: cdrom-mrw-poc.tar.gz --]
[-- Type: application/gzip, Size: 11481 bytes --]

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