CVE-2026-23005

概要

Linux カーネルにおいて、以下の脆弱性が解決されました: x86/fpu: ゲストのXSAVE状態においてXFD[i]=1のときは常にXSTATE_BV[i]をクリアする KVM_SET_XSAVEを介してゲストのXSAVE状態をロードする際、およびゲストのWRMSRに応じてXFDを更新する際に、保存された(または復元される)XSTATE_BV内のXFD無効化機能をクリアし、KVMがゲストのXFDを介して無効化された機能の状態をロードしようとしないようにします。カーネルはゲストのXFDを使用してXRSTORを実行するため、XFD[i]=1の状態でXSTATE_BV[i]=1を保存すると、XRSTORが#NMを発生させてカーネルがパニックを起こします。例えば、fpu_update_guest_xfd()がXSTATE_BVをクリアせずにXFDを設定した場合: ------------[ 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を設定し、vmexitハンドラのfpu_update_guest_xfd()呼び出しより前にホストのIRQがkernel_fpu_begin()をトリガーした場合に発生する可能性があります。また、ユーザースペースがKVM_SET_XSAVEを介してXSTATE_BV[i]=1を設定した場合: ------------[ 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アーキテクチャと整合性があります。IntelのSDMによると、XSAVEはXFDを介して無効化されたコンポーネントについてXSTATE_BVを'0'として保存します(非コンパクトXSAVEは状態コンポーネントの初期構成を保存します): XSAVE、XSAVEC、XSAVEOPT、またはXSAVESが状態コンポーネントiを保存している場合、XCR0[i] = IA32_XFD[i] = 1のとき、命令は#NMを生成しません。代わりに、XINUSE[i] = 0(および状態コンポーネントが初期状態)であるかのように動作します: XSAVEヘッダのXSTATE_BVフィールドのビットiを0として保存します。さらに、XSAVEは状態コンポーネントの初期構成を保存します(他の命令は状態コンポーネントiを保存しません)。あるいは、KVMは常にXFD=0でXRSTORを実行することもできます。例えば、struct fpu_guestのためにXSAVEingする際に有効な機能セットに基づく定数XFDを使用する方法です。しかし、XFD無効化機能に対してXSTATE_BV[i]=1が発生するのは、上記の割り込みケース、またはプリエンプティブルカーネルでのプリエンプションを伴う同様のシナリオのみです。なぜなら、fpu_swap_kvm_fpstate()のsave_fpregs_to_fpstate()呼び出しは、現在のXFDで送信元FPU状態を保存するからです。そしてそれは(XFDへの最初のWRMSR以外では)ゲストのXFDです。したがって、XFDがXSTATE_BVと同期しなくなるのは、上記の割り込みケース、またはプリエンプティブルカーネルでのプリエンプションを伴う同様のシナリオのみであり、KVM_GET_XSAVEがXFD無効化機能に対してXSTATE_BV[i]=0を返すことは(事実上)KVM ABIの一部と見なすことができます。 [Move clea ---truncated---