CVE-2025-37960 is a vulnerability identified in the Linux kernel's memory management subsystem, specifically within the memblock allocator. The issue arises in the function memblock_double_array(), which is responsible for increasing the size of an internal array used for memory allocation during early boot stages. When the slab allocator is not yet initialized, memblock_double_array() calls memblock_find_in_range() to reserve or allocate memory. However, the memory range returned by memblock_find_in_range() may not have been formally accepted by the system via accept_memory(), leading to a scenario where the kernel attempts to use unaccepted memory. This improper handling can cause a crash during the boot process, particularly affecting Secure Nested Paging (SNP) guests, which are virtual machines with enhanced security features. The crash manifests as a kernel panic or fatal error during memcpy operations, as indicated by the provided stack trace. The root cause is that the memory range is used before it is officially accepted, violating kernel memory management protocols. The mitigation involves ensuring that accept_memory() is called on the allocated memory range before the slab allocator becomes available, thereby formally accepting the memory and preventing the crash. Notably, the accept_memory() interface changed in Linux kernel version 6.12, switching from 'start' and 'end' parameters to 'start' and 'size'. Therefore, patches must account for this difference to maintain compatibility with kernels prior to v6.12. This vulnerability affects Linux kernel versions prior to the fix and is particularly relevant for environments running SNP-enabled virtual machines or similar configurations relying on early boot memory allocations. No known exploits are currently reported in the wild, and no CVSS score has been assigned yet.

For European organizations, this vulnerability poses a risk primarily to systems running affected Linux kernel versions, especially those utilizing virtualization technologies with SNP support, such as AMD SEV-SNP. The impact is a potential denial of service (DoS) through kernel crashes during system boot, which can disrupt availability of critical infrastructure, cloud services, and virtualized environments. Organizations relying on Linux-based servers, cloud platforms, or embedded systems with affected kernels may experience unexpected downtime or require emergency patching. Although this vulnerability does not directly lead to privilege escalation or data leakage, the inability to boot virtual machines or hosts can cause significant operational disruption. In sectors such as finance, healthcare, telecommunications, and government—where Linux servers and virtualization are widely deployed—this could affect service continuity and compliance with uptime requirements. Additionally, the complexity of the fix and kernel version dependencies may delay patch deployment, increasing exposure time. Since the vulnerability affects early boot memory management, recovery may require manual intervention or system reboots, complicating incident response. Overall, the threat is significant for European enterprises with large-scale Linux virtualization deployments or those using SNP-enabled hardware for enhanced security.

1. Immediate patching: Apply the official Linux kernel patches that ensure accept_memory() is called on the allocated memory range before slab allocator initialization. Verify kernel versions and apply backported fixes if using older kernels. 2. Kernel version management: Maintain an inventory of Linux kernel versions in use, prioritizing updates for systems running kernels prior to v6.12 or those known to be affected. 3. Virtualization environment review: Audit virtual machine configurations, especially those using SNP features, to identify vulnerable hosts. Consider temporarily disabling SNP or related features if patching is delayed and operational impact is critical. 4. Boot process monitoring: Implement monitoring to detect kernel panics or boot failures related to memblock or memory allocation issues, enabling rapid detection of exploitation attempts or crashes. 5. Testing and validation: Before deploying patches in production, conduct thorough testing in staging environments to ensure compatibility and stability, given the low-level nature of the fix. 6. Incident response readiness: Prepare recovery procedures for affected systems, including rescue boot options and kernel rollback plans, to minimize downtime in case of crashes. 7. Collaboration with vendors: Engage with Linux distribution maintainers and hardware vendors to obtain timely patches and guidance, especially for embedded or specialized systems. 8. Documentation and training: Educate system administrators and DevOps teams about the vulnerability, its impact, and the importance of early memory acceptance in kernel boot processes to improve awareness and response.