cdrom: cdrom_mrw_exit() NULL ptr deref

cdrom: cdrom_mrw_exit() NULL ptr deref

[Sergey Senozhatsky]

Hi,

We are seeing the same NULL ptr deref upon cdrom release, as reported
in [1] (Chris Cc-ed) in our fleet.  Currently on 6.6 LTS (could be the
same for older kernels as well, I didn't check.)

Phillip, is this a known issue?

<1>[335443.339244] BUG: kernel NULL pointer dereference, address: 0000000000000010
<1>[335443.339262] #PF: supervisor read access in kernel mode
<1>[335443.339268] #PF: error_code(0x0000) - not-present page
<6>[335443.339273] PGD 0 P4D 0
<4>[335443.339279] Oops: 0000 [#1] PREEMPT SMP NOPTI
<4>[335443.339287] CPU: 1 PID: 1988 Comm: cros-disks Not tainted 6.6.76-07501-gd42535a678fb #1 (HASH:7d84 1)
<4>[335443.339301] RIP: 0010:blk_queue_enter+0x5a/0x250
<4>[335443.339312] Code: 03 00 00 4c 8d 6d a8 eb 1c 4c 89 e7 4c 89 ee e8 8c 62 be ff 49 f7 86 88 00 00 00 02 00 00 00 0f 85 ce 01 00 00 e8 86 10 bd ff <49> 8b 07 a8 03 0f 85 85 01 00 00 65 48 ff 00 41 83 be 90 00 00 00
<4>[335443.339318] RSP: 0018:ffff9be08ab03b00 EFLAGS: 00010202
<4>[335443.339324] RAX: ffff8903aa366300 RBX: 0000000000000000 RCX: ffff9be08ab03cd0
<4>[335443.339330] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
<4>[335443.339333] RBP: ffff9be08ab03b58 R08: 0000000000000002 R09: 0000000000001b58
<4>[335443.339338] R10: ffffffff00000000 R11: ffffffffc0ccd030 R12: 0000000000000328
<4>[335443.339344] R13: ffff9be08ab03b00 R14: 0000000000000000 R15: 0000000000000010
<4>[335443.339348] FS: 00007d52be81e900(0000) GS:ffff8904b6040000(0000) knlGS:0000000000000000
<4>[335443.339357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[335443.339362] CR2: 0000000000000010 CR3: 0000000140ac6000 CR4: 0000000000350ee0
<4>[335443.339367] Call Trace:
<4>[335443.339372] <TASK>
<4>[335443.339379] ? __die_body+0xae/0xb0
<4>[335443.339389] ? page_fault_oops+0x381/0x3e0
<4>[335443.339398] ? exc_page_fault+0x4f/0xa0
<4>[335443.339404] ? asm_exc_page_fault+0x22/0x30
<4>[335443.339416] ? sr_check_events+0x290/0x290 [sr_mod (HASH:ab3e 2)]
<4>[335443.339432] ? blk_queue_enter+0x5a/0x250
<4>[335443.339439] blk_mq_alloc_request+0x16a/0x220
<4>[335443.339450] scsi_execute_cmd+0x65/0x240
<4>[335443.339458] sr_do_ioctl+0xe3/0x210 [sr_mod (HASH:ab3e 2)]
<4>[335443.339471] sr_packet+0x3d/0x50 [sr_mod (HASH:ab3e 2)]
<4>[335443.339482] cdrom_mrw_exit+0xc1/0x240 [cdrom (HASH:9d9a 3)]
<4>[335443.339497] sr_free_disk+0x45/0x60 [sr_mod (HASH:ab3e 2)]
<4>[335443.339506] disk_release+0xc8/0xe0
<4>[335443.339515] device_release+0x39/0x90
<4>[335443.339523] kobject_release+0x49/0xb0
<4>[335443.339533] bdev_release+0x19/0x30
<4>[335443.339540] deactivate_locked_super+0x3b/0x100
<4>[335443.339548] cleanup_mnt+0xaa/0x160
<4>[335443.339557] task_work_run+0x6c/0xb0
<4>[335443.339563] exit_to_user_mode_prepare+0x102/0x120
<4>[335443.339571] syscall_exit_to_user_mode+0x1a/0x30
<4>[335443.339577] do_syscall_64+0x7e/0xa0
<4>[335443.339582] ? exit_to_user_mode_prepare+0x44/0x120
<4>[335443.339588] entry_SYSCALL_64_after_hwframe+0x55/0xbf
<4>[335443.339595] RIP: 0033:0x7d52bea41f07

[1] https://lore.kernel.org/all/CAK2bqVJGsz8r8D-x=4N6p9nXQ=v4AwpMAg2frotmdSdtjvnexg@mail.gmail.com/

Re: cdrom: cdrom_mrw_exit() NULL ptr deref

[Phillip Potter]

On Fri, Jul 11, 2025 at 04:04:17PM +0900, Sergey Senozhatsky wrote:
> Hi,
> 
> We are seeing the same NULL ptr deref upon cdrom release, as reported
> in [1] (Chris Cc-ed) in our fleet.  Currently on 6.6 LTS (could be the
> same for older kernels as well, I didn't check.)
> 
> Phillip, is this a known issue?
> 
> <1>[335443.339244] BUG: kernel NULL pointer dereference, address: 0000000000000010
> <1>[335443.339262] #PF: supervisor read access in kernel mode
> <1>[335443.339268] #PF: error_code(0x0000) - not-present page
> <6>[335443.339273] PGD 0 P4D 0
> <4>[335443.339279] Oops: 0000 [#1] PREEMPT SMP NOPTI
> <4>[335443.339287] CPU: 1 PID: 1988 Comm: cros-disks Not tainted 6.6.76-07501-gd42535a678fb #1 (HASH:7d84 1)
> <4>[335443.339301] RIP: 0010:blk_queue_enter+0x5a/0x250
> <4>[335443.339312] Code: 03 00 00 4c 8d 6d a8 eb 1c 4c 89 e7 4c 89 ee e8 8c 62 be ff 49 f7 86 88 00 00 00 02 00 00 00 0f 85 ce 01 00 00 e8 86 10 bd ff <49> 8b 07 a8 03 0f 85 85 01 00 00 65 48 ff 00 41 83 be 90 00 00 00
> <4>[335443.339318] RSP: 0018:ffff9be08ab03b00 EFLAGS: 00010202
> <4>[335443.339324] RAX: ffff8903aa366300 RBX: 0000000000000000 RCX: ffff9be08ab03cd0
> <4>[335443.339330] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> <4>[335443.339333] RBP: ffff9be08ab03b58 R08: 0000000000000002 R09: 0000000000001b58
> <4>[335443.339338] R10: ffffffff00000000 R11: ffffffffc0ccd030 R12: 0000000000000328
> <4>[335443.339344] R13: ffff9be08ab03b00 R14: 0000000000000000 R15: 0000000000000010
> <4>[335443.339348] FS: 00007d52be81e900(0000) GS:ffff8904b6040000(0000) knlGS:0000000000000000
> <4>[335443.339357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> <4>[335443.339362] CR2: 0000000000000010 CR3: 0000000140ac6000 CR4: 0000000000350ee0
> <4>[335443.339367] Call Trace:
> <4>[335443.339372] <TASK>
> <4>[335443.339379] ? __die_body+0xae/0xb0
> <4>[335443.339389] ? page_fault_oops+0x381/0x3e0
> <4>[335443.339398] ? exc_page_fault+0x4f/0xa0
> <4>[335443.339404] ? asm_exc_page_fault+0x22/0x30
> <4>[335443.339416] ? sr_check_events+0x290/0x290 [sr_mod (HASH:ab3e 2)]
> <4>[335443.339432] ? blk_queue_enter+0x5a/0x250
> <4>[335443.339439] blk_mq_alloc_request+0x16a/0x220
> <4>[335443.339450] scsi_execute_cmd+0x65/0x240
> <4>[335443.339458] sr_do_ioctl+0xe3/0x210 [sr_mod (HASH:ab3e 2)]
> <4>[335443.339471] sr_packet+0x3d/0x50 [sr_mod (HASH:ab3e 2)]
> <4>[335443.339482] cdrom_mrw_exit+0xc1/0x240 [cdrom (HASH:9d9a 3)]
> <4>[335443.339497] sr_free_disk+0x45/0x60 [sr_mod (HASH:ab3e 2)]
> <4>[335443.339506] disk_release+0xc8/0xe0
> <4>[335443.339515] device_release+0x39/0x90
> <4>[335443.339523] kobject_release+0x49/0xb0
> <4>[335443.339533] bdev_release+0x19/0x30
> <4>[335443.339540] deactivate_locked_super+0x3b/0x100
> <4>[335443.339548] cleanup_mnt+0xaa/0x160
> <4>[335443.339557] task_work_run+0x6c/0xb0
> <4>[335443.339563] exit_to_user_mode_prepare+0x102/0x120
> <4>[335443.339571] syscall_exit_to_user_mode+0x1a/0x30
> <4>[335443.339577] do_syscall_64+0x7e/0xa0
> <4>[335443.339582] ? exit_to_user_mode_prepare+0x44/0x120
> <4>[335443.339588] entry_SYSCALL_64_after_hwframe+0x55/0xbf
> <4>[335443.339595] RIP: 0033:0x7d52bea41f07
> 
> [1] https://lore.kernel.org/all/CAK2bqVJGsz8r8D-x=4N6p9nXQ=v4AwpMAg2frotmdSdtjvnexg@mail.gmail.com/

Hi Sergey,

I have not been aware of this issue until now, as it pertains to the Uniform
CD-ROM driver, wasn't copied on the original bug report. Happy to do some
debugging by all means though. Please could you give me some more information
about how you're triggering it - i.e. is it particular discs? I am grateful
for any information you can provide.

Regards,
Phil

Re: cdrom: cdrom_mrw_exit() NULL ptr deref

[Sergey Senozhatsky]

On (25/07/11 21:46), Phillip Potter wrote:
> > <1>[335443.339244] BUG: kernel NULL pointer dereference, address: 0000000000000010
> > <1>[335443.339262] #PF: supervisor read access in kernel mode
> > <1>[335443.339268] #PF: error_code(0x0000) - not-present page
> > <6>[335443.339273] PGD 0 P4D 0
> > <4>[335443.339279] Oops: 0000 [#1] PREEMPT SMP NOPTI
> > <4>[335443.339287] CPU: 1 PID: 1988 Comm: cros-disks Not tainted 6.6.76-07501-gd42535a678fb #1 (HASH:7d84 1)
> > <4>[335443.339301] RIP: 0010:blk_queue_enter+0x5a/0x250
> > <4>[335443.339312] Code: 03 00 00 4c 8d 6d a8 eb 1c 4c 89 e7 4c 89 ee e8 8c 62 be ff 49 f7 86 88 00 00 00 02 00 00 00 0f 85 ce 01 00 00 e8 86 10 bd ff <49> 8b 07 a8 03 0f 85 85 01 00 00 65 48 ff 00 41 83 be 90 00 00 00
> > <4>[335443.339318] RSP: 0018:ffff9be08ab03b00 EFLAGS: 00010202
> > <4>[335443.339324] RAX: ffff8903aa366300 RBX: 0000000000000000 RCX: ffff9be08ab03cd0
> > <4>[335443.339330] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> > <4>[335443.339333] RBP: ffff9be08ab03b58 R08: 0000000000000002 R09: 0000000000001b58
> > <4>[335443.339338] R10: ffffffff00000000 R11: ffffffffc0ccd030 R12: 0000000000000328
> > <4>[335443.339344] R13: ffff9be08ab03b00 R14: 0000000000000000 R15: 0000000000000010
> > <4>[335443.339348] FS: 00007d52be81e900(0000) GS:ffff8904b6040000(0000) knlGS:0000000000000000
> > <4>[335443.339357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > <4>[335443.339362] CR2: 0000000000000010 CR3: 0000000140ac6000 CR4: 0000000000350ee0
> > <4>[335443.339367] Call Trace:
> > <4>[335443.339372] <TASK>
> > <4>[335443.339379] ? __die_body+0xae/0xb0
> > <4>[335443.339389] ? page_fault_oops+0x381/0x3e0
> > <4>[335443.339398] ? exc_page_fault+0x4f/0xa0
> > <4>[335443.339404] ? asm_exc_page_fault+0x22/0x30
> > <4>[335443.339416] ? sr_check_events+0x290/0x290 [sr_mod (HASH:ab3e 2)]
> > <4>[335443.339432] ? blk_queue_enter+0x5a/0x250
> > <4>[335443.339439] blk_mq_alloc_request+0x16a/0x220
> > <4>[335443.339450] scsi_execute_cmd+0x65/0x240
> > <4>[335443.339458] sr_do_ioctl+0xe3/0x210 [sr_mod (HASH:ab3e 2)]
> > <4>[335443.339471] sr_packet+0x3d/0x50 [sr_mod (HASH:ab3e 2)]
> > <4>[335443.339482] cdrom_mrw_exit+0xc1/0x240 [cdrom (HASH:9d9a 3)]
> > <4>[335443.339497] sr_free_disk+0x45/0x60 [sr_mod (HASH:ab3e 2)]
> > <4>[335443.339506] disk_release+0xc8/0xe0
> > <4>[335443.339515] device_release+0x39/0x90
> > <4>[335443.339523] kobject_release+0x49/0xb0
> > <4>[335443.339533] bdev_release+0x19/0x30
> > <4>[335443.339540] deactivate_locked_super+0x3b/0x100
> > <4>[335443.339548] cleanup_mnt+0xaa/0x160
> > <4>[335443.339557] task_work_run+0x6c/0xb0
> > <4>[335443.339563] exit_to_user_mode_prepare+0x102/0x120
> > <4>[335443.339571] syscall_exit_to_user_mode+0x1a/0x30
> > <4>[335443.339577] do_syscall_64+0x7e/0xa0
> > <4>[335443.339582] ? exit_to_user_mode_prepare+0x44/0x120
> > <4>[335443.339588] entry_SYSCALL_64_after_hwframe+0x55/0xbf
> > <4>[335443.339595] RIP: 0033:0x7d52bea41f07
> > 
> > [1] https://lore.kernel.org/all/CAK2bqVJGsz8r8D-x=4N6p9nXQ=v4AwpMAg2frotmdSdtjvnexg@mail.gmail.com/
> 
> Hi Sergey,

Hi Phillip,
Sorry for the delay in replying.

> I have not been aware of this issue until now, as it pertains to the Uniform
> CD-ROM driver, wasn't copied on the original bug report. Happy to do some
> debugging by all means though. Please could you give me some more information
> about how you're triggering it - i.e. is it particular discs? I am grateful
> for any information you can provide.

Doesn't seem to be specific to any particular disc, all sorts of
external CD/DVD drives that people attach to their laptops pop up
in the logs, e.g.:

<6>[333586.844993] usb 3-2: Product: Portable Super Multi Drive
<6>[333586.844998] usb 3-2: Manufacturer: Hitachi-LG Data Storage Inc
<5>[333587.915913] scsi 0:0:0:0: CD-ROM HL-DT-ST DVDRAM GP65NB60 PF00 PQ: 0 ANSI: 0
[..]

<6>[ 66.541922] usb-storage 3-2:1.0: USB Mass Storage device detected
<6>[ 66.542114] scsi host0: usb-storage 3-2:1.0
<5>[ 67.561667] scsi 0:0:0:0: CD-ROM Slimtype ES1 7L0M PQ: 0 ANSI: 0
[..]

<6>[26205.264565] usb 3-2: Manufacturer: JMicron
<6>[26205.267414] usb-storage 3-2:1.0: USB Mass Storage device detected
<6>[26205.267857] scsi host0: usb-storage 3-2:1.0
<5>[26206.329294] scsi 0:0:0:0: CD-ROM hp DVDRAM GT31L MR52 PQ: 0 ANSI: 0
[..]

And as soon as people detach the drives from their laptops, we get
the NULL queue dereference:

<6>[26369.017083] usb 3-2: USB disconnect, device number 2
<1>[26369.346200] BUG: kernel NULL pointer dereference, address: 0000000000000010
<1>[26369.346209] #PF: supervisor read access in kernel mode
<1>[26369.346213] #PF: error_code(0x0000) - not-present page
<6>[26369.346216] PGD 0 P4D 0
<4>[26369.346221] Oops: 0000 [#1] PREEMPT SMP NOPTI
<4>[26369.346226] CPU: 4 PID: 1787 Comm: cros-disks Not tainted 6.6.76-08054-g1b09a1d2f6c9 #1 (HASH:42d6 4)
<4>[26369.346235] RIP: 0010:blk_queue_enter+0x5a/0x250
[..]

The device is detached already, I assume there isn't much that
cdrom_mrw_exit() can do at that point.

Re: cdrom: cdrom_mrw_exit() NULL ptr deref

[Sergey Senozhatsky]

On (25/07/14 12:10), Sergey Senozhatsky wrote:
> Date: Mon, 14 Jul 2025 12:10:16 +0900
> From: Sergey Senozhatsky <senozhatsky@chromium.org>
> To: Phillip Potter <phil@philpotter.co.uk>
> Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,  Jens Axboe
>  <axboe@kernel.dk>, Christoph Hellwig <hch@infradead.org>,  Chris Rankin
>  <rankincj@gmail.com>, linux-kernel@vger.kernel.org,
>  linux-block@vger.kernel.org
> Subject: Re: cdrom: cdrom_mrw_exit() NULL ptr deref
> Message-ID: <7kbmle3wlpeqcnfieelypkxzypfxoh7bqmuqn2d3hbjgbcm7mt@cze3mv7htbeg>
> 
> On (25/07/11 21:46), Phillip Potter wrote:
> > > <1>[335443.339244] BUG: kernel NULL pointer dereference, address: 0000000000000010
> > > <4>[335443.339301] RIP: 0010:blk_queue_enter+0x5a/0x250
[..]
> > > <4>[335443.339439] blk_mq_alloc_request+0x16a/0x220
> > > <4>[335443.339450] scsi_execute_cmd+0x65/0x240
> > > <4>[335443.339458] sr_do_ioctl+0xe3/0x210 [sr_mod (HASH:ab3e 2)]
> > > <4>[335443.339471] sr_packet+0x3d/0x50 [sr_mod (HASH:ab3e 2)]
> > > <4>[335443.339482] cdrom_mrw_exit+0xc1/0x240 [cdrom (HASH:9d9a 3)]
> > > <4>[335443.339497] sr_free_disk+0x45/0x60 [sr_mod (HASH:ab3e 2)]
> > > <4>[335443.339506] disk_release+0xc8/0xe0
> > > <4>[335443.339515] device_release+0x39/0x90
> > > <4>[335443.339523] kobject_release+0x49/0xb0
> > > <4>[335443.339533] bdev_release+0x19/0x30
> > > <4>[335443.339540] deactivate_locked_super+0x3b/0x100
> > > <4>[335443.339548] cleanup_mnt+0xaa/0x160
> > > <4>[335443.339557] task_work_run+0x6c/0xb0
> > > <4>[335443.339563] exit_to_user_mode_prepare+0x102/0x120
> > > <4>[335443.339571] syscall_exit_to_user_mode+0x1a/0x30
> > > <4>[335443.339577] do_syscall_64+0x7e/0xa0
> > > <4>[335443.339582] ? exit_to_user_mode_prepare+0x44/0x120
> > > <4>[335443.339588] entry_SYSCALL_64_after_hwframe+0x55/0xbf
> > > <4>[335443.339595] RIP: 0033:0x7d52bea41f07
> > > 
[..]
> The device is detached already, I assume there isn't much that
> cdrom_mrw_exit() can do at that point.

If I read it correctly

<4>[335443.339482] cdrom_mrw_exit+0xc1/0x240 [cdrom (HASH:9d9a 3)]
<4>[335443.339497] sr_free_disk+0x45/0x60 [sr_mod (HASH:ab3e 2)]
<4>[335443.339506] disk_release+0xc8/0xe0
<4>[335443.339515] device_release+0x39/0x90

device_release() calls dev->type->release() before dev->class->dev_release().
dev->type->release() probably should be scsi_device_dev_release() which, among
other things, does sdev->request_queue = NULL, so dev->class->dev_release()
is called too late to execute any scsi commands.

Re: cdrom: cdrom_mrw_exit() NULL ptr deref

[Sergey Senozhatsky]

On (25/07/14 12:29), Sergey Senozhatsky wrote:
> [..]
> > The device is detached already, I assume there isn't much that
> > cdrom_mrw_exit() can do at that point.
> 
> If I read it correctly

Hmm, I don't think I did.

Re: cdrom: cdrom_mrw_exit() NULL ptr deref

[Jens Axboe]

On 7/11/25 2:46 PM, Phillip Potter wrote:
>> <1>[335443.339244] BUG: kernel NULL pointer dereference, address: 0000000000000010
>> <1>[335443.339262] #PF: supervisor read access in kernel mode
>> <1>[335443.339268] #PF: error_code(0x0000) - not-present page
>> <6>[335443.339273] PGD 0 P4D 0
>> <4>[335443.339279] Oops: 0000 [#1] PREEMPT SMP NOPTI
>> <4>[335443.339287] CPU: 1 PID: 1988 Comm: cros-disks Not tainted 6.6.76-07501-gd42535a678fb #1 (HASH:7d84 1)
>> <4>[335443.339301] RIP: 0010:blk_queue_enter+0x5a/0x250
>> <4>[335443.339312] Code: 03 00 00 4c 8d 6d a8 eb 1c 4c 89 e7 4c 89 ee e8 8c 62 be ff 49 f7 86 88 00 00 00 02 00 00 00 0f 85 ce 01 00 00 e8 86 10 bd ff <49> 8b 07 a8 03 0f 85 85 01 00 00 65 48 ff 00 41 83 be 90 00 00 00
>> <4>[335443.339318] RSP: 0018:ffff9be08ab03b00 EFLAGS: 00010202
>> <4>[335443.339324] RAX: ffff8903aa366300 RBX: 0000000000000000 RCX: ffff9be08ab03cd0
>> <4>[335443.339330] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
>> <4>[335443.339333] RBP: ffff9be08ab03b58 R08: 0000000000000002 R09: 0000000000001b58
>> <4>[335443.339338] R10: ffffffff00000000 R11: ffffffffc0ccd030 R12: 0000000000000328
>> <4>[335443.339344] R13: ffff9be08ab03b00 R14: 0000000000000000 R15: 0000000000000010
>> <4>[335443.339348] FS: 00007d52be81e900(0000) GS:ffff8904b6040000(0000) knlGS:0000000000000000
>> <4>[335443.339357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> <4>[335443.339362] CR2: 0000000000000010 CR3: 0000000140ac6000 CR4: 0000000000350ee0
>> <4>[335443.339367] Call Trace:
>> <4>[335443.339372] <TASK>
>> <4>[335443.339379] ? __die_body+0xae/0xb0
>> <4>[335443.339389] ? page_fault_oops+0x381/0x3e0
>> <4>[335443.339398] ? exc_page_fault+0x4f/0xa0
>> <4>[335443.339404] ? asm_exc_page_fault+0x22/0x30
>> <4>[335443.339416] ? sr_check_events+0x290/0x290 [sr_mod (HASH:ab3e 2)]
>> <4>[335443.339432] ? blk_queue_enter+0x5a/0x250
>> <4>[335443.339439] blk_mq_alloc_request+0x16a/0x220
>> <4>[335443.339450] scsi_execute_cmd+0x65/0x240
>> <4>[335443.339458] sr_do_ioctl+0xe3/0x210 [sr_mod (HASH:ab3e 2)]
>> <4>[335443.339471] sr_packet+0x3d/0x50 [sr_mod (HASH:ab3e 2)]
>> <4>[335443.339482] cdrom_mrw_exit+0xc1/0x240 [cdrom (HASH:9d9a 3)]
>> <4>[335443.339497] sr_free_disk+0x45/0x60 [sr_mod (HASH:ab3e 2)]
>> <4>[335443.339506] disk_release+0xc8/0xe0
>> <4>[335443.339515] device_release+0x39/0x90
>> <4>[335443.339523] kobject_release+0x49/0xb0
>> <4>[335443.339533] bdev_release+0x19/0x30
>> <4>[335443.339540] deactivate_locked_super+0x3b/0x100
>> <4>[335443.339548] cleanup_mnt+0xaa/0x160
>> <4>[335443.339557] task_work_run+0x6c/0xb0
>> <4>[335443.339563] exit_to_user_mode_prepare+0x102/0x120
>> <4>[335443.339571] syscall_exit_to_user_mode+0x1a/0x30
>> <4>[335443.339577] do_syscall_64+0x7e/0xa0
>> <4>[335443.339582] ? exit_to_user_mode_prepare+0x44/0x120
>> <4>[335443.339588] entry_SYSCALL_64_after_hwframe+0x55/0xbf
>> <4>[335443.339595] RIP: 0033:0x7d52bea41f07

This just looks totally broken, the cdrom layer trying to issue block
layer commands at exit time. Perhaps something like the below (utterly
untested) patch would be an improvement. Also gets rid of the silly
->exit() hook which exists just for mrw.


diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 21a10552da61..31ba1f8c1f78 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -624,9 +624,6 @@ int register_cdrom(struct gendisk *disk, struct cdrom_device_info *cdi)
 	if (check_media_type == 1)
 		cdi->options |= (int) CDO_CHECK_TYPE;
 
-	if (CDROM_CAN(CDC_MRW_W))
-		cdi->exit = cdrom_mrw_exit;
-
 	if (cdi->ops->read_cdda_bpc)
 		cdi->cdda_method = CDDA_BPC_FULL;
 	else
@@ -651,9 +648,6 @@ void unregister_cdrom(struct cdrom_device_info *cdi)
 	list_del(&cdi->list);
 	mutex_unlock(&cdrom_mutex);
 
-	if (cdi->exit)
-		cdi->exit(cdi);
-
 	cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" unregistered\n", cdi->name);
 }
 EXPORT_SYMBOL(unregister_cdrom);
@@ -1264,6 +1258,8 @@ void cdrom_release(struct cdrom_device_info *cdi)
 		cd_dbg(CD_CLOSE, "Use count for \"/dev/%s\" now zero\n",
 		       cdi->name);
 		cdrom_dvd_rw_close_write(cdi);
+		if (CDROM_CAN(CDC_MRW_W))
+			cdrom_mrw_exit(cdi);
 
 		if ((cdo->capability & CDC_LOCK) && !cdi->keeplocked) {
 			cd_dbg(CD_CLOSE, "Unlocking door!\n");
diff --git a/include/linux/cdrom.h b/include/linux/cdrom.h
index fdfb61ccf55a..b907e6c2307d 100644
--- a/include/linux/cdrom.h
+++ b/include/linux/cdrom.h
@@ -62,7 +62,6 @@ struct cdrom_device_info {
 	__u8 last_sense;
 	__u8 media_written;		/* dirty flag, DVD+RW bookkeeping */
 	unsigned short mmc3_profile;	/* current MMC3 profile */
-	int (*exit)(struct cdrom_device_info *);
 	int mrw_mode_page;
 	bool opened_for_data;
 	__s64 last_media_change_ms;

-- 
Jens Axboe

Re: cdrom: cdrom_mrw_exit() NULL ptr deref

[Phillip Potter]

On Mon, Jul 14, 2025 at 08:22:11AM -0600, Jens Axboe wrote:
> On 7/11/25 2:46 PM, Phillip Potter wrote:
> >> <1>[335443.339244] BUG: kernel NULL pointer dereference, address: 0000000000000010
> >> <1>[335443.339262] #PF: supervisor read access in kernel mode
> >> <1>[335443.339268] #PF: error_code(0x0000) - not-present page
> >> <6>[335443.339273] PGD 0 P4D 0
> >> <4>[335443.339279] Oops: 0000 [#1] PREEMPT SMP NOPTI
> >> <4>[335443.339287] CPU: 1 PID: 1988 Comm: cros-disks Not tainted 6.6.76-07501-gd42535a678fb #1 (HASH:7d84 1)
> >> <4>[335443.339301] RIP: 0010:blk_queue_enter+0x5a/0x250
> >> <4>[335443.339312] Code: 03 00 00 4c 8d 6d a8 eb 1c 4c 89 e7 4c 89 ee e8 8c 62 be ff 49 f7 86 88 00 00 00 02 00 00 00 0f 85 ce 01 00 00 e8 86 10 bd ff <49> 8b 07 a8 03 0f 85 85 01 00 00 65 48 ff 00 41 83 be 90 00 00 00
> >> <4>[335443.339318] RSP: 0018:ffff9be08ab03b00 EFLAGS: 00010202
> >> <4>[335443.339324] RAX: ffff8903aa366300 RBX: 0000000000000000 RCX: ffff9be08ab03cd0
> >> <4>[335443.339330] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> >> <4>[335443.339333] RBP: ffff9be08ab03b58 R08: 0000000000000002 R09: 0000000000001b58
> >> <4>[335443.339338] R10: ffffffff00000000 R11: ffffffffc0ccd030 R12: 0000000000000328
> >> <4>[335443.339344] R13: ffff9be08ab03b00 R14: 0000000000000000 R15: 0000000000000010
> >> <4>[335443.339348] FS: 00007d52be81e900(0000) GS:ffff8904b6040000(0000) knlGS:0000000000000000
> >> <4>[335443.339357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >> <4>[335443.339362] CR2: 0000000000000010 CR3: 0000000140ac6000 CR4: 0000000000350ee0
> >> <4>[335443.339367] Call Trace:
> >> <4>[335443.339372] <TASK>
> >> <4>[335443.339379] ? __die_body+0xae/0xb0
> >> <4>[335443.339389] ? page_fault_oops+0x381/0x3e0
> >> <4>[335443.339398] ? exc_page_fault+0x4f/0xa0
> >> <4>[335443.339404] ? asm_exc_page_fault+0x22/0x30
> >> <4>[335443.339416] ? sr_check_events+0x290/0x290 [sr_mod (HASH:ab3e 2)]
> >> <4>[335443.339432] ? blk_queue_enter+0x5a/0x250
> >> <4>[335443.339439] blk_mq_alloc_request+0x16a/0x220
> >> <4>[335443.339450] scsi_execute_cmd+0x65/0x240
> >> <4>[335443.339458] sr_do_ioctl+0xe3/0x210 [sr_mod (HASH:ab3e 2)]
> >> <4>[335443.339471] sr_packet+0x3d/0x50 [sr_mod (HASH:ab3e 2)]
> >> <4>[335443.339482] cdrom_mrw_exit+0xc1/0x240 [cdrom (HASH:9d9a 3)]
> >> <4>[335443.339497] sr_free_disk+0x45/0x60 [sr_mod (HASH:ab3e 2)]
> >> <4>[335443.339506] disk_release+0xc8/0xe0
> >> <4>[335443.339515] device_release+0x39/0x90
> >> <4>[335443.339523] kobject_release+0x49/0xb0
> >> <4>[335443.339533] bdev_release+0x19/0x30
> >> <4>[335443.339540] deactivate_locked_super+0x3b/0x100
> >> <4>[335443.339548] cleanup_mnt+0xaa/0x160
> >> <4>[335443.339557] task_work_run+0x6c/0xb0
> >> <4>[335443.339563] exit_to_user_mode_prepare+0x102/0x120
> >> <4>[335443.339571] syscall_exit_to_user_mode+0x1a/0x30
> >> <4>[335443.339577] do_syscall_64+0x7e/0xa0
> >> <4>[335443.339582] ? exit_to_user_mode_prepare+0x44/0x120
> >> <4>[335443.339588] entry_SYSCALL_64_after_hwframe+0x55/0xbf
> >> <4>[335443.339595] RIP: 0033:0x7d52bea41f07
> 
> This just looks totally broken, the cdrom layer trying to issue block
> layer commands at exit time. Perhaps something like the below (utterly
> untested) patch would be an improvement. Also gets rid of the silly
> ->exit() hook which exists just for mrw.
> 
> 
> diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
> index 21a10552da61..31ba1f8c1f78 100644
> --- a/drivers/cdrom/cdrom.c
> +++ b/drivers/cdrom/cdrom.c
> @@ -624,9 +624,6 @@ int register_cdrom(struct gendisk *disk, struct cdrom_device_info *cdi)
>  	if (check_media_type == 1)
>  		cdi->options |= (int) CDO_CHECK_TYPE;
>  
> -	if (CDROM_CAN(CDC_MRW_W))
> -		cdi->exit = cdrom_mrw_exit;
> -
>  	if (cdi->ops->read_cdda_bpc)
>  		cdi->cdda_method = CDDA_BPC_FULL;
>  	else
> @@ -651,9 +648,6 @@ void unregister_cdrom(struct cdrom_device_info *cdi)
>  	list_del(&cdi->list);
>  	mutex_unlock(&cdrom_mutex);
>  
> -	if (cdi->exit)
> -		cdi->exit(cdi);
> -
>  	cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" unregistered\n", cdi->name);
>  }
>  EXPORT_SYMBOL(unregister_cdrom);
> @@ -1264,6 +1258,8 @@ void cdrom_release(struct cdrom_device_info *cdi)
>  		cd_dbg(CD_CLOSE, "Use count for \"/dev/%s\" now zero\n",
>  		       cdi->name);
>  		cdrom_dvd_rw_close_write(cdi);
> +		if (CDROM_CAN(CDC_MRW_W))
> +			cdrom_mrw_exit(cdi);
>  
>  		if ((cdo->capability & CDC_LOCK) && !cdi->keeplocked) {
>  			cd_dbg(CD_CLOSE, "Unlocking door!\n");
> diff --git a/include/linux/cdrom.h b/include/linux/cdrom.h
> index fdfb61ccf55a..b907e6c2307d 100644
> --- a/include/linux/cdrom.h
> +++ b/include/linux/cdrom.h
> @@ -62,7 +62,6 @@ struct cdrom_device_info {
>  	__u8 last_sense;
>  	__u8 media_written;		/* dirty flag, DVD+RW bookkeeping */
>  	unsigned short mmc3_profile;	/* current MMC3 profile */
> -	int (*exit)(struct cdrom_device_info *);
>  	int mrw_mode_page;
>  	bool opened_for_data;
>  	__s64 last_media_change_ms;
> 
> -- 
> Jens Axboe

Happy to test. The patch makes a lot of sense. Will try and
recreate this as well - have just built 6.6 LTS and have it running in a
VM. Will report back. Many thanks.

Regards,
Phil

Re: cdrom: cdrom_mrw_exit() NULL ptr deref

[Sergey Senozhatsky]

On (25/07/14 08:22), Jens Axboe wrote:
> This just looks totally broken, the cdrom layer trying to issue block
> layer commands at exit time. Perhaps something like the below (utterly
> untested) patch would be an improvement. Also gets rid of the silly
> ->exit() hook which exists just for mrw.

I don't have a CD/DVD drive to test this, but from what I can tell
the patch looks good to me.  Thanks for taking a look!

Re: cdrom: cdrom_mrw_exit() NULL ptr deref

[Phillip Potter]

On Tue, Jul 15, 2025 at 12:32:22PM +0900, Sergey Senozhatsky wrote:
> On (25/07/14 08:22), Jens Axboe wrote:
> > This just looks totally broken, the cdrom layer trying to issue block
> > layer commands at exit time. Perhaps something like the below (utterly
> > untested) patch would be an improvement. Also gets rid of the silly
> > ->exit() hook which exists just for mrw.
> 
> I don't have a CD/DVD drive to test this, but from what I can tell
> the patch looks good to me.  Thanks for taking a look!

So thus far I've not been able to reproduce this. I've just ordered some
more rewritable discs though, so once they arrive I will produce some
proper sample discs and attempt to get it to crash again.

I will also run Jens's patch too with one of these discs to verify things
continue to work (and indeed that it improves things in the event I can
reproduce, which I'm sure it would).

Regards,
Phil

Re: cdrom: cdrom_mrw_exit() NULL ptr deref

[Phillip Potter]

On Tue, Jul 15, 2025 at 12:32:22PM +0900, Sergey Senozhatsky wrote:
> On (25/07/14 08:22), Jens Axboe wrote:
> > This just looks totally broken, the cdrom layer trying to issue block
> > layer commands at exit time. Perhaps something like the below (utterly
> > untested) patch would be an improvement. Also gets rid of the silly
> > ->exit() hook which exists just for mrw.
> 
> I don't have a CD/DVD drive to test this, but from what I can tell
> the patch looks good to me.  Thanks for taking a look!

Hi Sergey,

Just to say, I haven't forgotten this :-) Have run a few tests with the
patch and so far looks all good. Still been unable to replicate the
specific issue though. Assuming my testing uncovers nothing else, I will
revert to Jens with fully crafted patch submission in next day or two.

Regards,
Phil

Re: cdrom: cdrom_mrw_exit() NULL ptr deref

[Sergey Senozhatsky]

On (25/07/20 12:55), Phillip Potter wrote:
> > I don't have a CD/DVD drive to test this, but from what I can tell
> > the patch looks good to me.  Thanks for taking a look!
> 
> Hi Sergey,
> 
> Just to say, I haven't forgotten this :-) Have run a few tests with the
> patch and so far looks all good.

Hi Phillip,
Thanks for the update!

> Still been unable to replicate the specific issue though.

Hmm that's interesting.  I thought that unplugging a USB cdrom
drive would hit the issue relatively reliably.

> Assuming my testing uncovers nothing else, I will
> revert to Jens with fully crafted patch submission in next day or two.

Sounds like a plan.  Once we have an upstream patch we can cherry-pick
it and roll it out to our LTS kernels (and eventually to our users.)