CyberSecBulletin
CVE-2026-53360NVD status: Modified

Linux: Out-of-bounds Read

CVE-2026-53360 is a high-severity out-of-bounds read vulnerability in Linux, with a CVSS 3.1 base score of 8.8 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions bf9ba093fbb83c0c9a3dedd50efec29424eca2fc, c9b4198fbc6ed99a9da4bee9f74bb730f926c9ae, b328ede59ac34e7998e1eee5e5f0cc26c2a91846 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.3% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update Linux to bf9ba093fbb83c0c9a3dedd50efec29424eca2fc or c9b4198fbc6ed99a9da4bee9f74bb730f926c9ae or b328ede59ac34e7998e1eee5e5f0cc26c2a91846 or db3f2195d29344a3cf1e9dd9ab7f21ced7308cf7, whichever matches your release line, or a later version.
  2. Update Linux Kernel to 6.12.93 or 6.18.35 or 7.0.12, whichever matches your release line, or a later version.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinux4af663c2f64a8d252e690c60cf8b8abf22dc2951 up to, but not including, bf9ba093fbb83c0c9a3dedd50efec29424eca2fc; 4af663c2f64a8d252e690c60cf8b8abf22dc2951 up to, but not including, c9b4198fbc6ed99a9da4bee9f74bb730f926c9ae; 4af663c2f64a8d252e690c60cf8b8abf22dc2951 up to, but not including, b328ede59ac34e7998e1eee5e5f0cc26c2a91846; 4af663c2f64a8d252e690c60cf8b8abf22dc2951 up to, but not including, db3f2195d29344a3cf1e9dd9ab7f21ced7308cf7; 6.10bf9ba093fbb83c0c9a3dedd50efec29424eca2fc, c9b4198fbc6ed99a9da4bee9f74bb730f926c9ae, b328ede59ac34e7998e1eee5e5f0cc26c2a91846, db3f2195d29344a3cf1e9dd9ab7f21ced7308cf7
LinuxLinux Kernel6.10 up to, but not including, 6.12.93; 6.13 up to, but not including, 6.18.35; 6.19 up to, but not including, 7.0.12; 7.16.12.93, 6.18.35, 7.0.12

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
LocalThe attacker needs local access or must trick a user into running something.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
LowA basic user account is enough.
User interaction
NoneNo action by a victim is required.
Scope
ChangedThe attack can reach beyond the vulnerable component into other systems.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Scored by CNA.

Official 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]

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Out-of-bounds Read

The product reads data past the end, or before the beginning, of the intended buffer.

How developers prevent this class of flaw

  • Use a language that provides appropriate memory abstractions.

More Out-of-bounds Read vulnerabilities (CWE-125)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
  3. Record last changed materially (score, affected products, status or references).

References

Recent Out-of-bounds Read vulnerabilities

Spotted an error? Tell us.