Re: [PATCH v2 6/6] clocksource: hyper-v: Remove support for stimer interrupts in message mode

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 stim=
er 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 unconditiona=
lly
frees the active hv_clock_event per-CPU memory via free_percpu(hv_clock_eve=
nt)
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,=20
hv_stimer_global_cleanup() uses cpuhp_remove_state() to stop the timers. Th=
is
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 f=
ree
the percpu data?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260805203751.2678=
[email protected]?part=3D6