On (25/07/24 12:54), Sergey Senozhatsky wrote: > On (25/07/23 09:02), Phillip Potter wrote: > > On Wed, Jul 23, 2025 at 10:14:32AM +0900, Sergey Senozhatsky wrote: > > > On (25/07/23 00:18), Phillip Potter wrote: > > > > [..] I plan to do more digging regarding this, hopefully > > > > this weekend when I have some free time, as I'd really love to replicate > > > > the original crash. > > > > > > I waiting for LG GP65NB60 shipment (arriving today/tomorrow), which > > > shows up in crash reports (it should have CDC_MRW_W.) So I'll be able > > > to run some tests soon. > > > > Had to fake it with mine by forcing open the relevant code path for the > > check to be done. It still didn't crash, so I'll be interested to see > > your results > > 100% reproducible (at least on 6.6 LTS) with LG GP65. And unpatched 6.12 LTS sometimes UAFs [ 106.092832] ================================================================== [ 106.092866] BUG: KASAN: slab-use-after-free in sr_packet+0x179/0x1c0 [sr_mod] [ 106.092903] Read of size 8 at addr ffff888002a6c154 by task cros-disks/1958 [ 106.092943] CPU: 2 UID: 213 PID: 1958 Comm: cros-disks Not tainted 6.12.24-kasan-00964-g86abb5aa35ec [ 106.092969] Call Trace: [ 106.092976] <TASK> [ 106.092983] dump_stack_lvl+0x85/0xc0 [ 106.093007] print_address_description+0x72/0x210 [ 106.093023] print_report+0x4e/0x60 [ 106.093037] kasan_report+0x131/0x170 [ 106.093052] ? sr_packet+0x179/0x1c0 [sr_mod f28dbac28d644b5cb94db24e267ca134450739a2] [ 106.093075] sr_packet+0x179/0x1c0 [sr_mod f28dbac28d644b5cb94db24e267ca134450739a2] [ 106.093095] cdrom_mrw_exit+0xea/0x2e0 [cdrom 2d8b336738c9be415c8730ee14c0fc4e4c0367db] [ 106.093120] sr_free_disk+0x9a/0xc0 [sr_mod f28dbac28d644b5cb94db24e267ca134450739a2] [ 106.093138] disk_release+0x248/0x280 [ 106.093156] device_release+0x94/0x190 [ 106.093172] kobject_put+0x177/0x1f0 [ 106.093187] blkdev_release+0x11/0x20 [ 106.093201] __fput+0x1a7/0x7c0 [ 106.093221] task_work_run+0x107/0x180 [ 106.093240] resume_user_mode_work+0x4e/0x50 [ 106.093254] syscall_exit_to_user_mode+0x63/0xb0 [ 106.093268] do_syscall_64+0x76/0xe0 [ 106.093818] </TASK> [ 106.094277] Allocated by task 12: [ 106.094295] kasan_save_track+0x3a/0x80 [ 106.094318] __kasan_kmalloc+0x75/0x90 [ 106.094339] __kmalloc_noprof+0x18e/0x310 [ 106.094360] scsi_alloc_sdev+0x117/0x9d0 [ 106.094383] scsi_probe_and_add_lun+0x168/0x3670 [ 106.094405] __scsi_scan_target+0x121/0x7a0 [ 106.094426] scsi_scan_host_selected+0x291/0x4f0 [ 106.094448] do_scan_async+0x21b/0x710 [ 106.094469] async_run_entry_fn+0x97/0x360 [ 106.094490] process_scheduled_works+0x757/0xe20 [ 106.094512] worker_thread+0xb4c/0x1150 [ 106.094533] kthread+0x274/0x300 [ 106.094553] ret_from_fork+0x3b/0x70 [ 106.094576] ret_from_fork_asm+0x11/0x20 [ 106.094611] Freed by task 1958: [ 106.094628] kasan_save_track+0x3a/0x80 [ 106.094649] kasan_save_free_info+0x46/0x60 [ 106.094670] __kasan_slab_free+0x37/0x50 [ 106.094690] kfree+0x103/0x300 [ 106.094710] scsi_device_dev_release+0x95d/0x9d0 [ 106.094732] device_release+0x94/0x190 [ 106.094753] kobject_put+0x177/0x1f0 [ 106.094773] scsi_device_put+0x7f/0x90 [ 106.094793] bdev_release+0x46a/0x570 [ 106.094818] blkdev_release+0x11/0x20 [ 106.094836] __fput+0x1a7/0x7c0 [ 106.094856] task_work_run+0x107/0x180 [ 106.094880] resume_user_mode_work+0x4e/0x50 [ 106.094900] syscall_exit_to_user_mode+0x63/0xb0 [ 106.094920] do_syscall_64+0x76/0xe0 [ 106.094940] entry_SYSCALL_64_after_hwframe+0x55/0x5d The patched one doesn't.