Direct naar de inhoud
Kritieke cyberalerts voor jouw sector & systemen — direct in je inbox. Aanmelden →
cybernieuws.nl Cybersecurity en informatiebeveiling nieuws alerts live · 13 min 126 bronnen 3 kritiek 1 vandaag
CVE's Videos Dagbriefing

← Terug naar CVE-database

CVE-2026-64247

HIGH · 8.4 CVSS Gepubliceerd: CWE-125

Beschrijving NL

In de Linux kernel is de volgende kwetsbaarheid verholpen:

KVM: x86: hyper-v: Bound the bank index when querying sparse banks

Controleer bij het controleren of een VP-ID is opgenomen in een spaarzame bankset expliciet
dat de ID daadwerkelijk kan worden opgenomen in een spaarzame bank (de TLFS zorgt voor
maximaal 64 banken van elk 64 vCPU's). Bij het hanteren van een paravirtuele TLB
flush voor L2, wordt de VP-ID letterlijk overgenomen uit het verlichte VMCS,
zonder enige grenscontrole, d.w.z. is niet gegarandeerd onder de limiet van
4096. Het niet controleren van de grenzen van de VP-ID leidt tot een uitlezing buiten de grenzen
bij het testen van de spaarzame bank, en super strikt genomen zou kunnen leiden tot KVM
het uitvoeren van een onnodige TLB spoeling voor een L2 vCPU. ==================================================================
BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm]
Aflezen van maat 8 op adr ffff88811ba5f598 door taak hyperv_evmcs/2802

CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Niet besmet 7.1.0-rc2 #7 PREEMPT
Hardware naam: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Oproeptracering:

dump_stack_lvl+0x51/0x60
print_report+0xcb/0x5d0
kasan_report+0xb4/0xe0
kasan_check_ bereik+0x35/0x1b0
hv_is_vp_in_sparse_set+0x85/0x100 [kvm]
kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm]
kvm_hv_hypercall+0xe6b/0x1e60 [kvm]
vmx_handle_exit+0x485/0x1b60 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm]
kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm]
__x64_sys_ioctl+0x129/0x1a0
do_syscall_64+0xb9/0xcf0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f0e62d1a9bf

Het buggy-adres hoort bij de fysieke pagina:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffff pfn:0x11ba5f
vlaggen: 0x4000000000000000(zone=1)
rauw: 4000000000000000 0000000000000000 00000000ffffffffffffffffffffffffffffffffffffffffffffff
raw: ffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000
pagina gedumpt omdat: kasan: slechte toegang gedetecteerd

Geheugenstatus rond het buggy-adres:
ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
Foutopsporing bij vergrendeling uitschakelen vanwege kernelfout

Voeg op een opportunistische manier een compilatietijdbevestiging toe om het maximale aantal te garanderen
van schaarse banken exact overeenkomt met het aantal mogelijke bits in de doorgegeven
in masker. [sean: add KASAN splat, drop comment, add assert, massage changelog]

Origineel (Engels) tonen

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: hyper-v: Bound the bank index when querying sparse banks

When checking if a VP ID is included in a sparse bank set, explicitly check
that the ID can actually be contained in a sparse bank (the TLFS allows for
a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB
flush for L2, the VP ID is copied verbatim from the enlightened VMCS,
without any bounds check, i.e. isn't guaranteed to be under the limit of
4096.

Failure to check the bounds of the VP ID leads to an out-of-bounds read
when testing the sparse bank, and super strictly speaking could lead to KVM
performing an unnecessary TLB flush for an L2 vCPU.

==================================================================
BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm]
Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802

CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Call Trace:

dump_stack_lvl+0x51/0x60
print_report+0xcb/0x5d0
kasan_report+0xb4/0xe0
kasan_check_range+0x35/0x1b0
hv_is_vp_in_sparse_set+0x85/0x100 [kvm]
kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm]
kvm_hv_hypercall+0xe6b/0x1e60 [kvm]
vmx_handle_exit+0x485/0x1b60 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm]
kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm]
__x64_sys_ioctl+0x129/0x1a0
do_syscall_64+0xb9/0xcf0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f0e62d1a9bf

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f
flags: 0x4000000000000000(zone=1)
raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000
raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
Disabling lock debugging due to kernel taint

Opportunistically add a compile time assertion to ensure the maximum number
of sparse banks exactly matches the number of possible bits in the passed
in mask.

[sean: add KASAN splat, drop comment, add assert, massage changelog]

Vendors

Linux

Affected products

Linux Kernel

References