CVE-2026-23005

ملخص

في نواة لينكس، تم حل الثغرة الأمنية التالية: 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 سيؤدي إلى حدوث #NM في XRSTOR وانهيار النواة. على سبيل المثال، إذا قامت 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() قبل استدعاء معالج vmexit لـ fpu_update_guest_xfd(). وإذا قامت مساحة المستخدم بحشو 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. وفقًا لـ Intel's SDM، يحفظ 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 يمكن أن يحدث فقط في حالة المقاطعة أعلاه، أو في سيناريوهات مشابهة تتضمن استباقًا على النوى القابلة للاستباق، لأن استدعاء fpu_swap_kvm_fpstate() لـ save_fpregs_to_fpstate() يحفظ حالة FPU الصادرة مع XFD الحالي؛ وهذا (في جميع الحالات باستثناء أول WRMSR إلى XFD) هو XFD الخاص بالضيف. لذلك، يمكن أن يخرج XFD عن المزامنة مع XSTATE_BV فقط في حالة المقاطعة أعلاه، أو في سيناريوهات مشابهة تتضمن استباقًا على النوى القابلة للاستباق، ويمكننا اعتباره (بحكم الواقع) جزءًا من ABI الخاص بـ KVM أن KVM_GET_XSAVE يُرجع XSTATE_BV[i]=0 للميزات المعطلة عبر XFD. [نقل clea ---مقطوع---