CVE-2025-39996

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