The bounds check in snp_filter_reserved_mem_regions() validates space for entries already stored — num_elements * 16 bytes plus 8 bytes for the pending write base — but neglects the 4-byte page_count field that follows. At num_elements=255, this produces a 3-byte overflow into adjacent kernel heap memory. That's modest in isolation, but kernel heap overflows of any size are exploitable when they land on slab metadata, freelist pointers, or other adjacent objects under the kernel's control.
This is the third off-by-one in the CCP driver's range-list handling since 2019. CVE-2019-18817 and CVE-2021-47131 had the same semantic mismatch: validation checked current state (entries already stored) rather than next state (the entry about to be written). The pattern isn't coincidental — it's a propagated mental model that treats bounds checking as capacity validation rather than operation validation.
What you should do: First, verify whether your kernel version contains the fix (the patch adds explicit accounting for the entry about to be written). Second, audit sibling functions in the CCP and SEV drivers for the same pattern — look for 'num_elements * struct_size + overhead > PAGE_SIZE' checks that validate current state but don't account for pending writes. Third, trace the commit authorship across the three CVEs; they likely share reviewers, which means the institutional failure is at the review-chain level, not individual developer error.
The reachability question matters for severity calibration. This function is callable from an SNP guest through the #VMEXIT path when the guest requests memory range filtering — it does not require host-level code execution to trigger. That means a malicious guest VM can trigger the overflow, which elevates the practical risk beyond what the CVSS 7.8 vector alone captures. The 3-byte overflow needs to land on something the host trusts; prior CCP heap overflows in SNP contexts have demonstrated reliable heap grooming to hit sensitive adjacent fields.
The fix to this instance is straightforward. The harder problem is that the bounds-check template lives in developer muscle memory. Until static analysis or review checklists explicitly catch 'validate current state but write next state' mismatches, the same semantic error will continue appearing in new code.