Re: [PATCH v5 29/51] x86/kvm: Don't disable kvmclock on BSP in syscore_suspend()
Sean Christopherson <[email protected]>
| Newsgroups | org.kernel.vger.linux-hyperv,dev.linux.lists.sashiko-reviews,org.kernel.vger.kvm |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Jul 01, 2026, [email protected] wrote: > [Severity: High] > Does this change inadvertently leave the BSP's kvmclock enabled when > powering off the machine for ACPI S4 hibernation? > > Looking at the final S4 power-off path in hibernation_platform_enter() in > kernel/power/hibernate.c, it calls syscore_suspend() but does not call > save_processor_state(). Because this patch removes the unconditional BSP > kvmclock_disable() from syscore_suspend() and relies on > kvm_save_sched_clock_state() (which only fires during image creation), > kvmclock appears to remain fully enabled during the S4 power-off. No? hibernate() | -> hibernation_snapshot() | | | -> create_image() | | | -> save_processor_state() | -> power_down() | -> hibernation_platform_enter() I'm not familiar with the /dev/snapshot interface, but I gotta imagine userspace needs to do SNAPSHOT_CREATE_IMAGE before SNAPSHOT_POWER_OFF if it actually wants to restore state after S4. > [Severity: Critical] > This isn't a bug introduced by this patch, but is there a use-after-free > risk with the stack-allocated waitqueue head in the async page fault > handling in arch/x86/kernel/kvm.c? And I thought I had a problem with scope creep during review... > When a guest task waits for an async page fault in > kvm_async_pf_task_wait_schedule(), it waits on a stack-allocated struct > kvm_task_sleep_node. Concurrently, when a waker CPU executes > apf_task_wake_one(), it unhashes the node via hlist_del_init(). > > The waiter checks hlist_unhashed() locklessly. If it observes the unhashed > state before the waker is finished, the waiter can break its loop, return, > and destroy the stack frame. The waker might then dereference the > deallocated waitqueue head to call swake_up_one(), potentially corrupting > stack memory. > > Can this sequence occur during concurrent page fault completions? No idea, definitely something to sort out at a different time.