CVE-2026-23005

Резюме

В ядре Linux устранена следующая уязвимость: x86/fpu: очищать XSTATE_BV[i] в состоянии XSAVE гостя всякий раз, когда XFD[i]=1. При загрузке состояния XSAVE гостя через KVM_SET_XSAVE, а также при обновлении XFD в ответ на гостевой WRMSR, очищайте отключённые через XFD функции в сохранённом (или подлежащем восстановлению) XSTATE_BV, чтобы гарантировать, что KVM не пытается загрузить состояние для функций, отключённых через XFD гостя. Поскольку ядро выполняет XRSTOR с XFD гостя, сохранение XSTATE_BV[i]=1 при XFD[i]=1 приведёт к тому, что XRSTOR вызовет #NM и вызовет панику ядра. Например, если fpu_update_guest_xfd() устанавливает XFD без очистки XSTATE_BV: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848 Modules linked in: kvm_intel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 switch_fpu_return+0x4a/0xb0 kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- Это может произойти, если гость выполняет WRMSR(MSR_IA32_XFD) для установки XFD[18] = 1, а прерывание хоста запускает kernel_fpu_begin() до вызова fpu_update_guest_xfd() в обработчике vmexit. и если пользовательское пространство помещает XSTATE_BV[i]=1 через KVM_SET_XSAVE: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867 Modules linked in: kvm_intel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 fpu_swap_kvm_fpstate+0x6b/0x120 kvm_load_guest_fpu+0x30/0x80 [kvm] kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- Новое поведение согласуется с архитектурой AMX. Согласно SDM от Intel, XSAVE сохраняет XSTATE_BV как «0» для компонентов, отключённых через XFD (а некомпактный XSAVE сохраняет начальную конфигурацию компонента состояния): если XSAVE, XSAVEC, XSAVEOPT или XSAVES сохраняет компонент состояния i, инструкция не генерирует #NM, когда XCR0[i] = IA32_XFD[i] = 1; вместо этого она работает так, как если бы XINUSE[i] = 0 (и компонент состояния находился в начальном состоянии): она сохраняет бит i поля XSTATE_BV заголовка XSAVE как 0; кроме того, XSAVE сохраняет начальную конфигурацию компонента состояния (остальные инструкции не сохраняют компонент состояния i). Альтернативно, KVM мог бы всегда выполнять XRSTOR с XFD=0, например, используя константный XFD на основе набора включённых функций при XSAVE для struct fpu_guest. Однако наличие XSTATE_BV[i]=1 для отключённых через XFD функций может произойти только в вышеуказанном случае прерывания или в аналогичных сценариях, связанных с вытеснением на ядрах с поддержкой вытеснения, поскольку вызов save_fpregs_to_fpstate() в fpu_swap_kvm_fpstate() сохраняет исходящее состояние FPU с текущим XFD; а это (при всех, кроме первого, WRMSR к XFD) XFD гостя. Следовательно, XFD может рассинхронизироваться с XSTATE_BV только в вышеуказанном случае прерывания или в аналогичных сценариях, связанных с вытеснением на ядрах с поддержкой вытеснения, и мы можем считать это (де-факто) частью ABI KVM, что KVM_GET_XSAVE возвращает XSTATE_BV[i]=0 для отключённых через XFD функций. [Переместить clea ---оборвано---