Answer in brief
CVE-2024-40953 records a Unknown severity vulnerability in KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2024-40953 records a Unknown severity vulnerability in KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <11a772d5376aa6d3e2e69b5b5c585f79b60c0e17 || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <4c141136a28421b78f34969b25a4fa32e06e2180 || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <71fbc3af3dacb26c3aa2f30bb3ab05c44d082c84 || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <82bd728a06e55f5b5f93d10ce67f4fe7e689853a || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <92c77807d938145c7c3350c944ef9f39d7f6017c || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <a937ef951bba72f48d2402451419d725d70dba20 || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <95c8dd79f3a14df96b3820b35b8399bd91b2be60 || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <49f683b41f28918df3e51ddc0d928cb2e934ccdb | 11a772d5376aa6d3e2e69b5b5c585f79b60c0e17, 4c141136a28421b78f34969b25a4fa32e06e2180, 71fbc3af3dacb26c3aa2f30bb3ab05c44d082c84, 82bd728a06e55f5b5f93d10ce67f4fe7e689853a, 92c77807d938145c7c3350c944ef9f39d7f6017c, a937ef951bba72f48d2402451419d725d70dba20, 95c8dd79f3a14df96b3820b35b8399bd91b2be60, 49f683b41f28918df3e51ddc0d928cb2e934ccdb |
| Linux/Linuxgeneric | 2.6.39 | Not reported |
Published upstream
Jul 12, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin() Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <11a772d5376aa6d3e2e69b5b5c585f79b60c0e17 || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <4c141136a28421b78f34969b25a4fa32e06e2180 || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <71fbc3af3dacb26c3aa2f30bb3ab05c44d082c84 || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <82bd728a06e55f5b5f93d10ce67f4fe7e689853a || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <92c77807d938145c7c3350c944ef9f39d7f6017c || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <a937ef951bba72f48d2402451419d725d70dba20 || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <95c8dd79f3a14df96b3820b35b8399bd91b2be60 || >=217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 <49f683b41f28918df3e51ddc0d928cb2e934ccdb | 11a772d5376aa6d3e2e69b5b5c585f79b60c0e17, 4c141136a28421b78f34969b25a4fa32e06e2180, 71fbc3af3dacb26c3aa2f30bb3ab05c44d082c84, 82bd728a06e55f5b5f93d10ce67f4fe7e689853a, 92c77807d938145c7c3350c944ef9f39d7f6017c, a937ef951bba72f48d2402451419d725d70dba20, 95c8dd79f3a14df96b3820b35b8399bd91b2be60, 49f683b41f28918df3e51ddc0d928cb2e934ccdb |
| Linux/Linuxgeneric | 2.6.39 | Not reported |
Published upstream
Jul 12, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin() Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000
Quoted source text, attributed separately from HOL analysis.