{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.94-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.12-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003eend_entry;        if (idx_end \u003e= VMGEXIT_PSC_MAX_COUNT) {   // checks 253, not buffer           snp_complete_psc(svm, ...);           return 1;       }        for (idx = idx_start; idx \u003c= idx_end; idx++) {           entry_start = entries[idx];           // OOB when idx \u003e= 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]",
  "id": "DEBIAN-CVE-2026-53360",
  "modified": "2026-09-14T16:47:48.740134579Z",
  "published": "2026-07-04T12:17:01.880Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-53360"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-53360"
  ]
}