<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 11:29:28 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-53360 — KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-53360</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use&lt;/p&gt;
&lt;p&gt;As per the GHCB spec, when using GHCB v2+ require the software scratch area
to reside in the GHCB&amp;#39;s shared buffer.  Note, things like Page State Change
(PSC) requests _rely_ on this behavior, as the guest can&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;snp_begin_psc() validates end_entry against VMGEXIT_PSC_MAX_COUNT (253)
but NOT against the actual buffer size:&lt;/p&gt;
&lt;p&gt;idx_end = hdr-&amp;gt;end_entry;&lt;/p&gt;
&lt;p&gt;if (idx_end &amp;gt;= VMGEXIT_PSC_MAX_COUNT) {   // checks 253, not buffer
          snp_complete_psc(svm, ...);
          return 1;
      }&lt;/p&gt;
&lt;p&gt;for (idx = idx_start; idx &amp;lt;= idx_end; idx++) {
          entry_start = entries[idx];           // OOB when idx &amp;gt;= 2&lt;/p&gt;
&lt;p&gt;The guest sets end_entry=10+, causing the host to iterate entries[2+]
which are OOB into adjacent slab objects. For each OOB entry:…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use&lt;/p&gt;
&lt;p&gt;As per the GHCB spec, when using GHCB v2+ require the software scratch area
to reside in the GHCB&amp;#39;s shared buffer.  Note, things like Page State Change
(PSC) requests _rely_ on this behavior, as the guest can&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;snp_begin_psc() validates end_entry against VMGEXIT_PSC_MAX_COUNT (253)
but NOT against the actual buffer size:&lt;/p&gt;
&lt;p&gt;idx_end = hdr-&amp;gt;end_entry;&lt;/p&gt;
&lt;p&gt;if (idx_end &amp;gt;= VMGEXIT_PSC_MAX_COUNT) {   // checks 253, not buffer
          snp_complete_psc(svm, ...);
          return 1;
      }&lt;/p&gt;
&lt;p&gt;for (idx = idx_start; idx &amp;lt;= idx_end; idx++) {
          entry_start = entries[idx];           // OOB when idx &amp;gt;= 2&lt;/p&gt;
&lt;p&gt;The guest sets end_entry=10+, causing the host to iterate entries[2+]
which are OOB into adjacent slab objects. For each OOB entry:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-53360</guid>
    </item>
  </channel>
</rss>
