Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:

Pre-existing issues:
- [High] Use-After-Free of per-CPU clockevent devices during module unload or 
kexec.
--

--- Patch [6]: [PATCH v2 6/6] clocksource: hyper-v: Remove support for stimer 
interrupts in message mode ---
Note: The format of this report is altered and does not contain diff quotes due 
to recitation restrictions.

commit d696e5fb31caa79d07059889453363cd5e4a9522
Author: Michael Kelley <[email protected]>

clocksource: hyper-v: Remove support for stimer interrupts in message mode

This commit removes the legacy message-based delivery mechanism for Hyper-V
synthetic timers, making Direct Mode the only supported mechanism. The VMBus
driver no longer processes stimer interrupts, decoupling the two subsystems.

[Severity: High]
This is a pre-existing issue, but by removing the legacy teardown path, we
might be unconditionally exposing a use-after-free during module unload or
kexec.

Looking at hv_stimer_cleanup() in drivers/clocksource/hyperv_timer.c, the
code intentionally skips calling clockevents_unbind_device(), leaving the
clockevents registered in the core subsystem's linked list.

Then, in hv_stimer_global_cleanup() in the same file, the code unconditionally
frees the active hv_clock_event per-CPU memory via free_percpu(hv_clock_event)
while the structures are still registered in the clockevents core.

Can this result in dangling pointers in the core timekeeping lists? When the
hv_vmbus module is unloaded (vmbus_exit) or during a kexec, 
hv_stimer_global_cleanup() uses cpuhp_remove_state() to stop the timers. This
invokes hv_stimer_cleanup() on all online CPUs, which fails to unbind the
devices, and then the structures are freed.

Any subsequent traversal of the clockevent_devices list (such as servicing a
tick, reading /proc/timer_list, or adding another timer) could dereference
this freed memory. Should clockevents_unbind_device() be called before we free
the percpu data?

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=6

Reply via email to