CVE-2024-53196

In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Don't retire aborted MMIO instruction

Returning an abort to the guest for an unsupported MMIO access is a documented feature of the KVM UAPI. Nevertheless, it's clear that this plumbing has seen limited testing, since userspace can trivially cause a WARN in the MMIO return:

WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvmemulate.h:536 kvmhandlemmioreturn+0x46c/0x5c4 arch/arm64/include/asm/kvmemulate.h:536 Call trace: kvmhandlemmioreturn+0x46c/0x5c4 arch/arm64/include/asm/kvmemulate.h:536 kvmarchvcpuioctlrun+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvmvcpuioctl+0x75c/0xa78 virt/kvm/kvmmain.c:4487 __dosysioctl fs/ioctl.c:51 [inline] __sesysioctl fs/ioctl.c:893 [inline] __arm64sysioctl+0x14c/0x1c8 fs/ioctl.c:893 __invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0svccommon+0x1e0/0x23c arch/arm64/kernel/syscall.c:132 doel0svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t64synchandler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t64sync+0x190/0x194 arch/arm64/kernel/entry.S:598

The splat is complaining that KVM is advancing PC while an exception is pending, i.e. that KVM is retiring the MMIO instruction despite a pending synchronous external abort. Womp womp.

Fix the glaring UAPI bug by skipping over all the MMIO emulation in case there is a pending synchronous exception. Note that while userspace is capable of pending an asynchronous exception (SError, IRQ, or FIQ), it is still safe to retire the MMIO instruction in this case as (1) they are by definition asynchronous, and (2) KVM relies on hardware support for pending/delivering these exceptions instead of the software state machine for advancing PC.