CVE-2022-49557: x86/fpu: KVM: Set the base guest FPU uABI size to sizeof(struct kvm_xsave)
In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: KVM: Set the base guest FPU uABI size to sizeof(struct kvmxsave)
Set the starting uABI size of KVM's guest FPU to 'struct kvmxsave', i.e. to KVM's historical uABI size. When saving FPU state for usersapce, KVM (well, now the FPU) sets the FP+SSE bits in the XSAVE header even if the host doesn't support XSAVE. Setting the XSAVE header allows the VM to be migrated to a host that does support XSAVE without the new host having to handle FPU state that may or may not be compatible with XSAVE.
Setting the uABI size to the host's default size results in out-of-bounds writes (setting the FP+SSE bits) and data corruption (that is thankfully caught by KASAN) when running on hosts without XSAVE, e.g. on Core2 CPUs.
WARN if the default size is larger than KVM's historical uABI size; all features that can push the FPU size beyond the historical size must be opt-in.
================================================================== BUG: KASAN: slab-out-of-bounds in fpucopyuabitoguestfpstate+0x86/0x130 Read of size 8 at addr ffff888011e33a00 by task qemu-build/681 CPU: 1 PID: 681 Comm: qemu-build Not tainted 5.18.0-rc5-KASAN-amd64 #1 Hardware name: /DG35EC, BIOS ECG3510M.86A.0118.2010.0113.1426 01/13/2010 Call Trace: <TASK> dumpstacklvl+0x34/0x45 printreport.cold+0x45/0x575 kasanreport+0x9b/0xd0 fpucopyuabitoguestfpstate+0x86/0x130 kvmarchvcpuioctl+0x72a/0x1c50 [kvm] kvmvcpuioctl+0x47f/0x7b0 [kvm] x64sysioctl+0x5de/0xc90 dosyscall64+0x31/0x50 entrySYSCALL64afterhwframe+0x44/0xae </TASK> Allocated by task 0: (stack is not available) The buggy address belongs to the object at ffff888011e33800 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 0 bytes to the right of 512-byte region [ffff888011e33800, ffff888011e33a00) The buggy address belongs to the physical page: page:0000000089cd4adb refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11e30 head:0000000089cd4adb order:2 compoundmapcount:0 compoundpincount:0 flags: 0x4000000000010200(slab|head|zone=1) raw: 4000000000010200 dead000000000100 dead000000000122 ffff888001041c80 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888011e33900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888011e33980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888011e33a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888011e33a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888011e33b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
KVM hosts that save guest FPU state for userspace while running on CPUs without XSAVE support are affected. Core2 CPUs are specifically identified as an example.
What conditions trigger the memory corruption?
The issue occurs when the host's default guest FPU uABI size is used and KVM sets FP and SSE bits in the XSAVE header. On hosts without XSAVE, this can write beyond the allocated FPU-state buffer.
How can an administrator identify a potential occurrence?
KASAN can report a slab out-of-bounds access in fpu_copy_uabi_to_guest_fpstate during the affected path. The example report shows the access occurring in a QEMU process while saving guest FPU state.