tty: timbuart: tasklet may trigger UAF during remove

[LI xiao]

Hello,

I suspect a tasklet lifetime race in the timbuart driver that may lead to a UAF.

timbuart_remove() calls tasklet_kill(&uart->tasklet) before uart_remove_one_port(), then frees uart. The IRQ handler schedules the same tasklet. An IRQ occurring after tasklet_kill() returns but before the IRQ is freed and synchronized during port shutdown may queue the tasklet again. The subsequent IRQ synchronization does not itself drain a tasklet that has already been queued, potentially allowing it to access the freed uart object.

I tested this ordering on Linux 7.3 (commit c03c1a14507dfaf8b856c2608f9ac216021fc222) using a KASAN kernel in a 2-vCPU QEMU guest. A test module forced the relevant ordering by scheduling the tasklet after tasklet_kill(), keeping the softirq pending, freeing the owner, and then allowing the tasklet to run. KASAN reported:

BUG: KASAN: slab-use-after-free in tasklet_action_common+0x605/0x780
Read of size 8 ... by task timbuart-repro-
Call Trace:
tasklet_action_common
handle_softirqs
do_softirq
__local_bh_enable_ip
simulated_irq [timbuart_tasklet_repro]

Allocated by:
__kmalloc_cache_noprof
timbuart_tasklet_repro_init [timbuart_tasklet_repro]

Freed by:
kfree
timbuart_tasklet_repro_init [timbuart_tasklet_repro]

This reproducer validates the tasklet ordering and UAF scenario, but it does not emulate Timberdale UART hardware or exercise timbuart's actual IRQ handler. The real hardware interrupt path has not been verified.

Could you review whether the driver teardown has this race and advise on the appropriate fix?

Thanks,
LI Xiao