"Linux 5.5 overhauled the internal state handling for the iopl() and ioperm()
system calls. Unfortunately, one aspect on context switch wasn't wired up
correctly for the Xen PVOps case.
IO port permissions don't get rescinded when context switching to an
unprivileged task. Therefore, all userspace can use the IO ports granted to
the most recently scheduled task with IO port permissions.
Only x86 guests are vulnerable.
All versions of Linux from 5.5 are potentially vulnerable.
Linux is only vulnerable when running as x86 PV guest. Linux is not
vulnerable when running as an x86 HVM/PVH guests.
The vulnerability can only be exploited in domains which have been granted
access to IO ports by Xen. This is typically only the hardware domain, and
guests configured with PCI Passthrough."
Please apply this patch if appropriate: https://lists.xenproject.org/archives/html/xen-announce/2020-07/binjSCTODhPNE.bin
This is fixed in Linux Kernel in versions 5.5+, nothing to do in Xen. Since we don't have a stable kernel above 5.4, we can just prune kernel <5.7.10.
Author: Andy Lutomirski <email@example.com>
Date: Fri Jul 17 16:53:55 2020 -0700
x86/ioperm: Fix io bitmap invalidation on Xen PV
commit cadfad870154e14f745ec845708bc17d166065f2 upstream.
tss_invalidate_io_bitmap() wasn't wired up properly through the pvop
machinery, so the TSS and Xen's io bitmap would get out of sync
whenever disabling a valid io bitmap.
Add a new pvop for tss_invalidate_io_bitmap() to fix it.
This is XSA-329.
Fixes: 22fe5b0439dd ("x86/ioperm: Move TSS bitmap update to exit to user work")
Signed-off-by: Andy Lutomirski <firstname.lastname@example.org>
Signed-off-by: Thomas Gleixner <email@example.com>
Reviewed-by: Juergen Gross <firstname.lastname@example.org>
Reviewed-by: Thomas Gleixner <email@example.com>
Signed-off-by: Greg Kroah-Hartman <firstname.lastname@example.org>
(In reply to Tomáš Mózes from comment #3)
> This is fixed in Linux Kernel in versions 5.5+, nothing to do in Xen. Since
> we don't have a stable kernel above 5.4, we can just prune kernel <5.7.10.
Thanks. CCing kernel@.
(yes, apologies -- it was a bit late!)
Kernel issue so no GLSA; no affected kernels in tree. Closing.