CVE-2024-50017 in Linuxinfo

Summary

by MITRE • 10/21/2024

In the Linux kernel, the following vulnerability has been resolved:

x86/mm/ident_map: Use gbpages only where full GB page should be mapped.

When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts.

Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request.

No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 03/22/2026

The vulnerability identified as CVE-2024-50017 resides within the x86 memory management subsystem of the Linux kernel, specifically in the ident_map implementation that handles identity mapping of memory regions. This flaw manifests in how the kernel allocates memory page table entries when creating identity mappings for physical memory regions. The issue is particularly concerning because it affects the fundamental memory management operations that underpin system security and stability, especially on systems utilizing the Unified Virtual (UV) architecture. The vulnerability stems from an overly aggressive approach to memory mapping where the kernel uses 1GB page mappings even when only small portions of that memory space are actually required, creating unintended consequences that extend far beyond the intended memory boundaries.

The technical root cause of this vulnerability lies in the ident_pud_init() function's handling of page table entries. When this function processes memory mapping requests, it defaults to using 1GB page mappings (gbpages) regardless of the actual size of the requested memory region. This means that even a 4KB memory allocation request will trigger the creation of a full 1GB page table entry, which includes address ranges that were never explicitly requested. The kernel's memory management system does not properly evaluate whether the requested memory boundaries align with 1GB page boundaries, leading to the inclusion of extensive address space that may contain reserved regions marked by the BIOS. This behavior creates a speculative execution vulnerability where processor microarchitectural features might access memory regions that should remain protected, particularly problematic on UV systems where such access can result in complete system halts rather than just security violations.

The operational impact of this vulnerability extends beyond simple memory management inefficiencies to potentially catastrophic system stability issues. On Unified Virtual systems, the speculative access into reserved memory regions can cause the entire system to halt or crash, representing a denial-of-service condition that could be exploited by malicious actors. The vulnerability affects the kernel's memory management during early boot phases and system initialization, potentially compromising the integrity of the system's memory protection mechanisms. Additionally, this flaw can create unexpected behavior in memory allocation patterns where the kernel's memory management decisions affect the overall system performance and resource utilization. The issue is particularly dangerous because it operates at a low level in the kernel, making detection and mitigation challenging for system administrators and security analysts.

The mitigation strategy implemented in the fix addresses the core issue by modifying the page mapping logic to use 1GB pages only when the memory mapping request explicitly requires a full 1GB page of contiguous memory. This approach ensures that when only portions of a 1GB region are requested, the system falls back to using 2MB page mappings, which are more granular and prevent the inclusion of unwanted reserved memory regions. The solution maintains backward compatibility while significantly reducing the risk of speculative execution into protected memory areas. However, the fix does not implement advanced coalescing of mapping requests, meaning that the kernel continues to use the most recently determined page size for subsequent requests within the same 1GB region, which could potentially lead to less efficient memory usage patterns but avoids the more serious security implications. This implementation aligns with common security practices for memory management systems and reduces the attack surface while maintaining system stability. The vulnerability classification aligns with CWE-129, which addresses improper validation of array indices, and could be categorized under ATT&CK technique T1059.001 for command and scripting interpreter, as the vulnerability could potentially be exploited through memory manipulation attacks that leverage the speculative execution behavior.

Responsible

Linux

Reservation

10/21/2024

Disclosure

10/21/2024

Moderation

accepted

CPE

ready

EPSS

0.00220

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!