CVE-2026-23005

सारांश

लिनक्स कर्नेल में, निम्नलिखित भेद्यता को हल किया गया है: x86/fpu: जब भी XFD[i]=1 हो, गेस्ट XSAVE स्थिति में 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 ]--- यह तब हो सकता है जब गेस्ट XFD[18] = 1 सेट करने के लिए WRMSR(MSR_IA32_XFD) निष्पादित करता है, और vmexit हैंडलर की fpu_update_guest_xfd() कॉल से पहले एक होस्ट IRQ kernel_fpu_begin() को ट्रिगर करता है। और यदि userspace 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 उन घटकों के लिए XSTATE_BV को '0' के रूप में सहेजता है जो XFD के माध्यम से अक्षम हैं (और गैर-संकुचित XSAVE स्थिति घटक का प्रारंभिक कॉन्फ़िगरेशन सहेजता है): यदि XSAVE, XSAVEC, XSAVEOPT, या XSAVES स्थिति घटक i को सहेज रहा है, तो निर्देश #NM उत्पन्न नहीं करता है जब XCR0[i] = IA32_XFD[i] = 1; इसके बजाय, यह ऐसे कार्य करता है जैसे 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 ABI का हिस्सा मान सकते हैं कि KVM_GET_XSAVE XFD-अक्षम सुविधाओं के लिए XSTATE_BV[i]=0 लौटाता है। [Move clea ---छंटा हुआ---