CVE-2026-53360
Beschrijving NL
In de Linux kernel is de volgende kwetsbaarheid verholpen:
KVM: SEV: Vereist in-GHCB krasgebied als GHCB v2+ in gebruik is
Volgens de GHCB-specificatie is bij gebruik van GHCB v2+ het krasgebied van de software vereist
om te verblijven in de gedeelde buffer van de GHCB. Let op, dingen zoals paginastatuswijziging
(PSC) requests _rely_ op dit gedrag, omdat de gast geen lengte kan opgeven
bij het indienen van het verzoek, d.w.z. de grootte van de payload van de gast wordt begrensd door
de grootte van de gedeelde buffer. Het niet forceren van het gebruik van de GHCB, en een hele reeks andere gebreken, laat een
kwaadaardige SNP gast corrupte host kernel heap geheugen, en lek host heap
lay-outinformatie. setup_vmgexit_scratch() wijst een buffer toe via kvzalloc(exit_info_2),
waarbij exit_INFO_2 door gasten wordt beheerd. Bij exit_info_2=24 levert dit
een 24-byte toewijzing in kmalloc-cg-32 (32-byte plaatobjecten). De buffer
bevat een 8-byte psc_hdr gevolgd door 8-byte psc_entry structs, dus alleen
entries[0] en entries[1] zijn in-bounds. snp_begin_psc() valideert END_entry tegen VMGEXIT_PSC_MAX_COUNT (253)
maar NIET tegen de werkelijke buffergrootte:
idx_end = hdr->END_entry;
if (idx_END >= VMGEXIT_PSC_MAX_COUNT) { // controleert 253, geen buffer
snp_complete_psc(svm, ...);
return 1;
}
voor (idx = idx_start; idx = 2
De gast stelt END_entry=10+ in, waardoor de host de invoer herhaalt [2+]
die OOB zijn in aangrenzende plaatobjecten. Voor elke OOB-ingang:
- De host leest 8 bytes (OOB READ / info leak oracle)
- Als de gegevens de PSC-validatie doorstaan, schrijft __snp_complete_ONE_psc()
cur_page = 1 of 512 in het item (OOB SCHRIJVEN, sev.c:3806)
- Als de validatie mislukt, onthult de foutreactie of aangrenzende
geheugen is nul versus niet-nul (openbaarmaking van informatie aan gast)
De gast bepaalt de toewijzingsgrootte (exit_info_2), het invoerbereik
(CUR_entry/END_entry), en kan onbeperkt VMGEXITs afvuren om herhaaldelijk
hoi t verschillende plakposities. Door gebruik te maken van de verscheidenheid aan bugs, kan een kwaadwillende SEV-SNP-gast:
- OOB gelezen aangrenzende kmalloc-cg-32-objecten (openbaarmaking van heaplay-out)
- OOB schrijf cur_page bits in aangrenzende objecten (heap corruptie)
- Activeer gebruiks-na-vrije omstandigheden in VMGEXIT's
Bijv. met KASAN ingeschakeld, een enkele insmod van de PoC-gastmodule
produceert 73 KASAN-rapporten:
BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x126/0x890
Aflezen van maat 8 op adr ffff888219ffb5e0 door taak qemu-system-x86/2199
BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x468/0x890
Schrijf van maat 8 op adr ffff888351566648 door taak qemu-system-x86/2199
Het buggy-adres hoort bij het object op ffff888XXXXXXXXXXX
die behoort tot de cache kmalloc-cg-32 van si ze 32
Het buggy-adres bevindt zich N bytes rechts van
toegewezen 32-byte regio [ffff888XXXXXXXXX, ffff888XXXXXXXXX)
Uitsplitsing:
62 slab-out-of-bounds (leest + schrijft verleden toewijzing)
7 slab-use-after-free
4 use-after-free
Alle eer aan Stan voor de prachtige beschrijving en reproducent! [sean: write changelog]
Origineel (Engels) tonen
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use
As per the GHCB spec, when using GHCB v2+ require the software scratch area
to reside in the GHCB's shared buffer. Note, things like Page State Change
(PSC) requests _rely_ on this behavior, as the guest can't provide a length
when making the request, i.e. the size of the guest payload is bounded by
the size of the shared buffer.
Failure to force usage of the GHCB, and a slew of other flaws, lets a
malicious SNP guest corrupt host kernel heap memory, and leak host heap
layout information.
setup_vmgexit_scratch() allocates a buffer via kvzalloc(exit_info_2),
where exit_info_2 is guest-controlled. With exit_info_2=24, this yields
a 24-byte allocation in kmalloc-cg-32 (32-byte slab objects). The buffer
holds an 8-byte psc_hdr followed by 8-byte psc_entry structs, so only
entries[0] and entries[1] are in-bounds.
snp_begin_psc() validates end_entry against VMGEXIT_PSC_MAX_COUNT (253)
but NOT against the actual buffer size:
idx_end = hdr->end_entry;
if (idx_end >= VMGEXIT_PSC_MAX_COUNT) { // checks 253, not buffer
snp_complete_psc(svm, ...);
return 1;
}
for (idx = idx_start; idx = 2
The guest sets end_entry=10+, causing the host to iterate entries[2+]
which are OOB into adjacent slab objects. For each OOB entry:
- The host reads 8 bytes (OOB READ / info leak oracle)
- If the data passes PSC validation, __snp_complete_one_psc() writes
cur_page = 1 or 512 into the entry (OOB WRITE, sev.c:3806)
- If validation fails, the error response reveals whether adjacent
memory is zero vs non-zero (information disclosure to guest)
The guest controls allocation size (exit_info_2), entry range
(cur_entry/end_entry), and can fire unlimited VMGEXITs to repeatedly
hit different slab positions.
By exploiting the variety of bugs, a malicious SEV-SNP guest can:
- OOB read adjacent kmalloc-cg-32 objects (heap layout disclosure)
- OOB write cur_page bits into adjacent objects (heap corruption)
- Trigger use-after-free conditions across VMGEXITs
E.g. with KASAN enabled, a single insmod of the PoC guest module
produces 73 KASAN reports:
BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x126/0x890
Read of size 8 at addr ffff888219ffb5e0 by task qemu-system-x86/2199
BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x468/0x890
Write of size 8 at addr ffff888351566648 by task qemu-system-x86/2199
The buggy address belongs to the object at ffff888XXXXXXXXX
which belongs to the cache kmalloc-cg-32 of size 32
The buggy address is located N bytes to the right of
allocated 32-byte region [ffff888XXXXXXXXX, ffff888XXXXXXXXX)
Breakdown:
62 slab-out-of-bounds (reads + writes past allocation)
7 slab-use-after-free
4 use-after-free
All credit to Stan for the wonderful description and reproducer!
[sean: write changelog]