linux-kernel - Re: cdrom: cdrom_mrw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fcoixqhllcn4cjycwse253zeyg27bghyrsablmlw6cdz7c27xj@3tzfom227xrq>
Date: Mon, 14 Jul 2025 12:29:04 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Phillip Potter <phil@...lpotter.co.uk>
Cc: Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@...radead.org>, 
	Chris Rankin <rankincj@...il.com>, linux-kernel@...r.kernel.org, linux-block@...r.kernel.org, 
	Sergey Senozhatsky <senozhatsky@...omium.org>
Subject: Re: cdrom: cdrom_mrw_exit() NULL ptr deref

On (25/07/14 12:10), Sergey Senozhatsky wrote:
> Date: Mon, 14 Jul 2025 12:10:16 +0900
> From: Sergey Senozhatsky <senozhatsky@...omium.org>
> To: Phillip Potter <phil@...lpotter.co.uk>
> Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,  Jens Axboe
>  <axboe@...nel.dk>, Christoph Hellwig <hch@...radead.org>,  Chris Rankin
>  <rankincj@...il.com>, linux-kernel@...r.kernel.org,
>  linux-block@...r.kernel.org
> Subject: Re: cdrom: cdrom_mrw_exit() NULL ptr deref
> Message-ID: <7kbmle3wlpeqcnfieelypkxzypfxoh7bqmuqn2d3hbjgbcm7mt@...3mv7htbeg>
> 
> 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.