Re: [PATCH] can: kvaser_pciefd: fix use-after-free in bec poll timer
Fan Wu <[email protected]>
| Newsgroups | org.kernel.vger.linux-can,org.kernel.vger.linux-kernel,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
Hi Marc, Yes. The driver has three timer_delete() call sites, all for bec_poll_timer. The calls in kvaser_pciefd_bus_on() and kvaser_pciefd_stop() are runtime cancellations: the CAN device stays alive after both, and the timer must stay rearmable for the next open/bus-on cycle, since the interrupt handler arms it from handle_error_packet(), handle_status_resp() and handle_status_packet(). Converting either one to timer_shutdown_sync() would make those later mod_timer() calls no-ops. The stop() flush-timeout path, which skips its timer_delete() entirely, is also covered: the device is still alive there, and remove() still shuts the timer down unconditionally. kvaser_pciefd_remove() is different: its timer_delete() is followed by free_irq() and then by the final free_candev(), while the interrupt handler can still rearm the timer. That is the call converted by this patch, which also adds timer_shutdown_sync() to kvaser_pciefd_teardown_can_ctrls(), the probe-error path that frees the CAN devices after free_irq(). Thanks, Fan > On Aug 18, 2026, at 20:00, Marc Kleine-Budde <[email protected]> wrote: > > On 18.08.2026 06:38:32, Fan Wu wrote: >> The bec poll timer is rearmed from the interrupt handler, so the >> timer_delete() call in kvaser_pciefd_remove() neither waits for a > > There are more timer_delete() in the code, have you had a look at them, > too? > > regards, > Marc