On 12.01.2024 00:13, Andrew Cooper wrote:
> When receiving an INIT, a prior bugfix tried to ignore the INIT and continue
> onwards.
>
> Unfortunately it's not safe to return at that point in vmx_vmexit_handler().
> Just out of context in the first hunk is a local_irqs_enabled() which is
> depended-upon by the return-to-guest path, causing the following checklock
> failure in debug builds:
>
> (XEN) Error: INIT received - ignoring
> (XEN) CHECKLOCK FAILURE: prev irqsafe: 0, curr irqsafe 1
> (XEN) Xen BUG at common/spinlock.c:132
> (XEN) ----[ Xen-4.19-unstable x86_64 debug=y Tainted: H ]----
> ...
> (XEN) Xen call trace:
> (XEN) [<ffff82d040238e10>] R check_lock+0xcd/0xe1
> (XEN) [<ffff82d040238fe3>] F _spin_lock+0x1b/0x60
> (XEN) [<ffff82d0402ed6a8>] F pt_update_irq+0x32/0x3bb
> (XEN) [<ffff82d0402b9632>] F vmx_intr_assist+0x3b/0x51d
> (XEN) [<ffff82d040206447>] F vmx_asm_vmexit_handler+0xf7/0x210
>
> Luckily, this is benign in release builds. Accidentally having IRQs disabled
> when trying to take an IRQs-on lock isn't a deadlock-vulnerable pattern.
>
> Drop the problematic early return. In hindsight, it's wrong to skip other
> normal VMExit steps.
>
> Fixes: b1f11273d5a7 ("x86/vmx: Don't spuriously crash the domain when INIT is
> received")
> Reported-by: Reima ISHII <[email protected]>
> Signed-off-by: Andrew Cooper <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
