KVM/arm64 fixes for 6.8, take #3
Marc Zyngier
maintainerHey Paolo,
Another week, another couple of fixes. This time, two fixes for the ITS emulation that could result in non-existent LPIs being used, with unpredictable consequences. Thanks to Oliver for spotting those as he was reworking the ITS translation cache.
Please pull,
M.
The following changes since commit c60d847be7b8e69e419e02a2b3d19c2842a3c35d:
KVM: arm64: Fix double-free following kvm_pgtable_stage2_free_unlinked() (2024-02-13 19:22:03 +0000)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-6.8-3
for you to fetch changes up to 85a71ee9a0700f6c18862ef3b0011ed9dad99aca:
KVM: arm64: vgic-its: Test for valid IRQ in MOVALL handler (2024-02-21 10:06:41 +0000)
----------------------------------------------------------------
KVM/arm64 fixes for 6.8, take #3
- Check for the validity of interrupts handled by a MOVALL command
- Check for the validity of interrupts while reading the pending state on enabling LPIs.
----------------------------------------------------------------
Oliver Upton (2):
KVM: arm64: vgic-its: Test for valid IRQ in its_sync_lpi_pending_table()
KVM: arm64: vgic-its: Test for valid IRQ in MOVALL handler
arch/arm64/kvm/vgic/vgic-its.c | 5 +++++ 1 file changed, 5 insertions(+)
Paolo Bonzini
maintainerQuoted 7 lines · Marc Zyngier
Hey Paolo,
Another week, another couple of fixes. This time, two fixes for the ITS emulation that could result in non-existent LPIs being used, with unpredictable consequences. Thanks to Oliver for spotting those as he was reworking the ITS translation cache.
The consequences would really be NULL pointer dereferences, wouldn't they?
Pulled, thanks (not pushed so that I can adjust the merge commit message).
Paolo
Marc Zyngier
maintainerQuoted 11 lines · Paolo Bonzini
Quoted 7 lines · Marc Zyngier
Hey Paolo,
Another week, another couple of fixes. This time, two fixes for the ITS emulation that could result in non-existent LPIs being used, with unpredictable consequences. Thanks to Oliver for spotting those as he was reworking the ITS translation cache.
The consequences would really be NULL pointer dereferences, wouldn't they?
That's the effect. The consequences depend on how the fault is handled ('benign' oops, panic, or reboot...).
Thanks,
M.
Signature · 1 line
Without deviation from the norm, progress is not possible.