CVE-2025-39996: In the Linux kernel, the following vulnerability has been resolved:  media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove  The original code uses cancel_delayed_work() in flexcop_pci_remove(), which does not guarantee that the delayed work item irq_check_work has fully completed if it was already running. This leads to use-after-free scenarios where flexcop_pci_remove() may free the flexcop_device while irq_check_work is still active and attempts to dereference the device.  A typical race condition is illustrated below:  CPU 0 (remove)                         | CPU 1 (delayed work callback) flexcop_pci_remove()                   | flexcop_pci_irq_check_work()   cancel_delayed_work()                |   flexcop_device_kfree(fc_pci->fc_dev) |                                        |   fc = fc_pci->fc_dev; // UAF  This is confirmed by a KASAN report:  ================================================================== BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff8880093aa8c8 by task bash/135 ... Call Trace:  <IRQ>  dump_stack_lvl+0x55/0x70  print_report+0xcf/0x610  ? __run_timer_base.part.0+0x7d7/0x8c0  kasan_report+0xb8/0xf0  ? __run_timer_base.part.0+0x7d7/0x8c0  __run_timer_base.part.0+0x7d7/0x8c0  ? __pfx___run_timer_base.part.0+0x10/0x10  ? __pfx_read_tsc+0x10/0x10  ? ktime_get+0x60/0x140  ? lapic_next_event+0x11/0x20  ? clockevents_program_event+0x1d4/0x2a0  run_timer_softirq+0xd1/0x190  handle_softirqs+0x16a/0x550  irq_exit_rcu+0xaf/0xe0  sysvec_apic_timer_interrupt+0x70/0x80  </IRQ> ...  Allocated by task 1:  kasan_save_stack+0x24/0x50  kasan_save_track+0x14/0x30  __kasan_kmalloc+0x7f/0x90  __kmalloc_noprof+0x1be/0x460  flexcop_device_kmalloc+0x54/0xe0  flexcop_pci_probe+0x1f/0x9d0  local_pci_probe+0xdc/0x190  pci_device_probe+0x2fe/0x470  really_probe+0x1ca/0x5c0  __driver_probe_device+0x248/0x310  driver_probe_device+0x44/0x120  __driver_attach+0xd2/0x310  bus_for_each_dev+0xed/0x170  bus_add_driver+0x208/0x500  driver_register+0x132/0x460  do_one_initcall+0x89/0x300  kernel_init_freeable+0x40d/0x720  kernel_init+0x1a/0x150  ret_from_fork+0x10c/0x1a0  ret_from_fork_asm+0x1a/0x30  Freed by task 135:  kasan_save_stack+0x24/0x50  kasan_save_track+0x14/0x30  kasan_save_free_info+0x3a/0x60  __kasan_slab_free+0x3f/0x50  kfree+0x137/0x370  flexcop_device_kfree+0x32/0x50  pci_device_remove+0xa6/0x1d0  device_release_driver_internal+0xf8/0x210  pci_stop_bus_device+0x105/0x150  pci_stop_and_remove_bus_device_locked+0x15/0x30  remove_store+0xcc/0xe0  kernfs_fop_write_iter+0x2c3/0x440  vfs_write+0x871/0xd70  ksys_write+0xee/0x1c0  do_syscall_64+0xac/0x280  entry_SYSCALL_64_after_hwframe+0x77/0x7f ...  Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work has finished before the device memory is deallocated.  This bug was initially identified through static analysis. To reproduce and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced artificial delays within the flexcop_pci_irq_check_work() function to increase the likelihood of triggering the bug.