In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokunucsiprobe() but never properly canceled in gaokunucsiremove(). This creates use-after-free scenarios where the ucsi and gaokunucsi structure are freed after ucsidestroy() completes execution, while the gaokunucsiregisterworker() might be either currently executing or still pending in the work queue. The already-freed gaokunucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __runtimers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: showstack+0x18/0x24 (C) dumpstacklvl+0x78/0x90 printreport+0x114/0x580 kasanreport+0xa4/0xf0 __asanreportstore8_noabort+0x20/0x2c __runtimers+0x5ec/0x630 runtimersoftirq+0xe8/0x1cc handlesoftirqs+0x294/0x720 __do_softirq+0x14/0x20 ____dosoftirq+0x10/0x1c callonirqstack+0x30/0x48 do_softirqownstack+0x1c/0x28 __irqexitrcu+0x27c/0x364 irqexitrcu+0x10/0x1c el1interrupt+0x40/0x60 el1h64irqhandler+0x18/0x24 el1h64irq+0x6c/0x70 archlocalirqenable+0x4/0x8 (P) doidle+0x334/0x458 cpustartupentry+0x60/0x70 restinit+0x158/0x174 startkernel+0x2f8/0x394 __primaryswitched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasansavestack+0x2c/0x54 kasansavetrack+0x24/0x5c kasansaveallocinfo+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmallocnodetrackcallernoprof+0x1c0/0x588 devmkmalloc+0x7c/0x1c8 gaokunucsiprobe+0xa0/0x840 auxiliarybusprobe+0x94/0xf8 reallyprobe+0x17c/0x5b8 __driverprobedevice+0x158/0x2c4 driverprobedevice+0x10c/0x264 __deviceattachdriver+0x168/0x2d0 bus_foreachdrv+0x100/0x188 __deviceattach+0x174/0x368 deviceinitialprobe+0x14/0x20 busprobedevice+0x120/0x150 deviceadd+0xb3c/0x10fc __auxiliarydeviceadd+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasansavestack+0x2c/0x54 kasansavetrack+0x24/0x5c __kasansavefree_info+0x4c/0x74 __kasanslabfree+0x60/0x8c kfree+0xd4/0x410 devresreleaseall+0x140/0x1f0 deviceunbindcleanup+0x20/0x190 devicereleasedriverinternal+0x344/0x460 devicereleasedriver+0x18/0x24 busremovedevice+0x198/0x274 devicedel+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entiremapcount:0 nrpagesmapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) pagetype: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---