CVE-2026-53360

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use<br /> <br /> As per the GHCB spec, when using GHCB v2+ require the software scratch area<br /> to reside in the GHCB&amp;#39;s shared buffer. Note, things like Page State Change<br /> (PSC) requests _rely_ on this behavior, as the guest can&amp;#39;t provide a length<br /> when making the request, i.e. the size of the guest payload is bounded by<br /> the size of the shared buffer.<br /> <br /> Failure to force usage of the GHCB, and a slew of other flaws, lets a<br /> malicious SNP guest corrupt host kernel heap memory, and leak host heap<br /> layout information.<br /> <br /> setup_vmgexit_scratch() allocates a buffer via kvzalloc(exit_info_2),<br /> where exit_info_2 is guest-controlled. With exit_info_2=24, this yields<br /> a 24-byte allocation in kmalloc-cg-32 (32-byte slab objects). The buffer<br /> holds an 8-byte psc_hdr followed by 8-byte psc_entry structs, so only<br /> entries[0] and entries[1] are in-bounds.<br /> <br /> snp_begin_psc() validates end_entry against VMGEXIT_PSC_MAX_COUNT (253)<br /> but NOT against the actual buffer size:<br /> <br /> idx_end = hdr-&gt;end_entry;<br /> <br /> if (idx_end &gt;= VMGEXIT_PSC_MAX_COUNT) { // checks 253, not buffer<br /> snp_complete_psc(svm, ...);<br /> return 1;<br /> }<br /> <br /> for (idx = idx_start; idx = 2<br /> <br /> The guest sets end_entry=10+, causing the host to iterate entries[2+]<br /> which are OOB into adjacent slab objects. For each OOB entry:<br /> <br /> - The host reads 8 bytes (OOB READ / info leak oracle)<br /> - If the data passes PSC validation, __snp_complete_one_psc() writes<br /> cur_page = 1 or 512 into the entry (OOB WRITE, sev.c:3806)<br /> - If validation fails, the error response reveals whether adjacent<br /> memory is zero vs non-zero (information disclosure to guest)<br /> <br /> The guest controls allocation size (exit_info_2), entry range<br /> (cur_entry/end_entry), and can fire unlimited VMGEXITs to repeatedly<br /> hit different slab positions.<br /> <br /> By exploiting the variety of bugs, a malicious SEV-SNP guest can:<br /> - OOB read adjacent kmalloc-cg-32 objects (heap layout disclosure)<br /> - OOB write cur_page bits into adjacent objects (heap corruption)<br /> - Trigger use-after-free conditions across VMGEXITs<br /> <br /> E.g. with KASAN enabled, a single insmod of the PoC guest module<br /> produces 73 KASAN reports:<br /> <br /> BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x126/0x890<br /> Read of size 8 at addr ffff888219ffb5e0 by task qemu-system-x86/2199<br /> <br /> BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x468/0x890<br /> Write of size 8 at addr ffff888351566648 by task qemu-system-x86/2199<br /> <br /> The buggy address belongs to the object at ffff888XXXXXXXXX<br /> which belongs to the cache kmalloc-cg-32 of size 32<br /> The buggy address is located N bytes to the right of<br /> allocated 32-byte region [ffff888XXXXXXXXX, ffff888XXXXXXXXX)<br /> <br /> Breakdown:<br /> 62 slab-out-of-bounds (reads + writes past allocation)<br /> 7 slab-use-after-free<br /> 4 use-after-free<br /> <br /> All credit to Stan for the wonderful description and reproducer!<br /> <br /> [sean: write changelog]