CVE-2026-74404 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one
Sashiko notes:
> regarding the bounds check in snp_filter_reserved_mem_regions() > called via walk_iomem_res_desc(): does the check > if ((range_list->num_elements * 16 + 8) > PAGE_SIZE) > allow an off-by-one heap buffer overflow? > > If range_list->num_elements is 255, 255 * 16 + 8 = 4088, which is <= 4096. > Writing range->base (8 bytes) fills 4088-4095, but writing range->page_count > (4 bytes) would write to 4096-4099, overflowing the kzalloc-allocated > PAGE_SIZE buffer.
Fix this by accounting for the entry about to be written to, in addition to the entries that are already allocated.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability identified in the Linux kernel's crypto ccp subsystem represents a critical heap buffer overflow condition that could potentially enable arbitrary code execution or system compromise. This issue resides within the snp_filter_reserved_mem_regions() function which is invoked through walk_iomem_res_desc() during memory region processing operations. The flaw manifests as an off-by-one error in bounds checking logic that fails to account for the additional memory required when writing a new entry into the reserved memory region list.
The technical implementation of this vulnerability stems from improper calculation of buffer boundaries within the memory allocation scheme. Specifically, the condition if ((range_list->num_elements * 16 + 8) > PAGE_SIZE) demonstrates flawed arithmetic that does not properly consider the memory footprint of entries being written to the buffer. When range_list->num_elements reaches 255, the calculation yields 4088 bytes which appears to fit within a 4096 byte PAGE_SIZE buffer. However, this calculation fails to account for the fact that each entry requires both base address (8 bytes) and page_count (4 bytes) fields, totaling 12 bytes per entry rather than the 16 bytes assumed in the original bounds check.
This vulnerability aligns with CWE-121 Stack-based Buffer Overflow and CWE-787 Out-of-bounds Write classifications, representing a classic heap overflow condition that can be exploited through controlled memory manipulation. The operational impact of this flaw extends beyond simple memory corruption as it affects the kernel's ability to properly manage reserved memory regions during Secure Nested Paging (SNP) operations. Such issues are particularly concerning in virtualization contexts where proper memory isolation is critical for maintaining system integrity.
The exploitability of this vulnerability through ATT&CK framework mappings would likely involve techniques such as privilege escalation and code injection, with the specific TTPs falling under privilege escalation through kernel exploits and defense evasion via memory corruption attacks. The fix implemented addresses the fundamental calculation error by incorporating the entry about to be written into the bounds checking logic rather than only considering existing allocated entries. This correction ensures that the buffer size calculation properly accounts for all memory requirements including the new entry being added to the list.
The resolution demonstrates proper defensive programming practices that align with kernel security hardening guidelines, specifically addressing memory allocation boundary conditions in kernel space operations. This fix exemplifies the importance of precise arithmetic in kernel-level memory management where even minor miscalculations can result in critical security vulnerabilities. The patch validates that the buffer size calculation accounts for the complete memory footprint including both existing entries and the new entry being processed, thereby preventing the overflow condition that could otherwise be exploited by malicious actors to gain elevated privileges or cause system instability.
The broader implications of this vulnerability highlight the complexity of kernel memory management operations and the critical need for comprehensive testing of boundary conditions in security-sensitive code paths. This issue underscores the importance of thorough code reviews focusing on arithmetic calculations and buffer management within kernel subsystems, particularly those handling hardware virtualization features like SNP that require precise memory layout control. The fix serves as a reminder of the critical nature of proper bounds checking in kernel space operations where memory corruption can lead to complete system compromise rather than mere application-level failures.
This vulnerability type represents a common class of issues in kernel development where developers must carefully consider not just existing data structures but also the implications of adding new elements to those structures. The fix demonstrates that proper defensive programming requires accounting for all potential memory requirements including future additions to data structures, rather than only considering current state conditions. Such vulnerabilities emphasize the need for automated testing tools and formal verification methods in kernel security development processes to catch these subtle but critical arithmetic errors before they can be exploited in production environments.