Skip to main content
VulnerabilityPublished Updated

CVE-2026-53360: Linux kernel · Out-of-bounds Write

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 8.8 High · fixed in db3f2195d29344a3cf1e9dd9ab7f21ced7308cf7 : patch Linux kernel soon.

Data as of 26 Oct 2026, 13:47 UTC

CVSS 3.1 base score
8.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.2% chance of exploitation in 30 days – higher than 22% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in db3f2195d29344a3cf1e9dd9ab7f21ced7308cf7, c9b4198fbc6ed99a9da4bee9f74bb730f926c9ae, bf9ba093fbb83c0c9a3dedd50efec29424eca2fc +1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 4 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade Linux kernel to db3f2195d29344a3cf1e9dd9ab7f21ced7308cf7, c9b4198fbc6ed99a9da4bee9f74bb730f926c9ae, bf9ba093fbb83c0c9a3dedd50efec29424eca2fc or b328ede59ac34e7998e1eee5e5f0cc26c2a91846.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 4af663c2f64a8d252e690c60cf8b8abf22dc2951, < db3f2195d29344a3cf1e9dd9ab7f21ced7308cf7
Fixed in
  • db3f2195d29344a3cf1e9dd9ab7f21ced7308cf7
LinuxLinuxAffected
  • ≥ 4af663c2f64a8d252e690c60cf8b8abf22dc2951, < c9b4198fbc6ed99a9da4bee9f74bb730f926c9ae
Fixed in
  • c9b4198fbc6ed99a9da4bee9f74bb730f926c9ae
LinuxLinuxAffected
  • ≥ 4af663c2f64a8d252e690c60cf8b8abf22dc2951, < bf9ba093fbb83c0c9a3dedd50efec29424eca2fc
Fixed in
  • bf9ba093fbb83c0c9a3dedd50efec29424eca2fc
LinuxLinuxAffected
  • ≥ 4af663c2f64a8d252e690c60cf8b8abf22dc2951, < b328ede59ac34e7998e1eee5e5f0cc26c2a91846
Fixed in
  • b328ede59ac34e7998e1eee5e5f0cc26c2a91846
LinuxLinuxAffected
  • =6.10
Fixed in–

Description

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 <= idx_end; idx++) { entry_start = entries[idx]; // OOB when 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]

References

Community reviews

Loading reviews…