CVE-2024-36019 in Linux
Summary
by MITRE • 05/30/2024
In the Linux kernel, the following vulnerability has been resolved:
regmap: maple: Fix cache corruption in regcache_maple_drop()
When keeping the upper end of a cache block entry, the entry[] array
must be indexed by the offset from the base register of the block, i.e. max - mas.index.
The code was indexing entry[] by only the register address, leading
to an out-of-bounds access that copied some part of the kernel memory over the cache contents.
This bug was not detected by the regmap KUnit test because it only tests with a block of registers starting at 0, so mas.index == 0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 05/07/2026
The vulnerability CVE-2024-36019 represents a critical memory corruption flaw within the Linux kernel's regmap subsystem, specifically affecting the maple tree implementation used for register caching operations. This issue resides in the regcache_maple_drop() function which manages cache invalidation and memory management for register maps. The flaw manifests when the system attempts to maintain portions of cached register data while dropping others, creating a scenario where memory boundaries are improperly handled during cache operations.
The technical root cause of this vulnerability stems from improper array indexing within the cache management logic. When processing cache blocks, the code incorrectly calculates the array index for the entry[] array by using the absolute register address instead of the relative offset from the base register of the block. This fundamental miscalculation occurs at the mathematical boundary where max - mas.index should be used to determine the correct array position, but instead the absolute register address is employed. This error creates a direct path for out-of-bounds memory access that can overwrite critical cache contents with arbitrary kernel memory data.
The operational impact of this vulnerability extends beyond simple memory corruption, as it provides potential attack vectors for privilege escalation and system instability. An attacker capable of triggering the specific cache invalidation scenario could potentially manipulate kernel memory structures, leading to denial of service conditions or more severe exploitation opportunities. The vulnerability's exploitation requires careful crafting of register map configurations that activate the problematic code path, making it less trivial to exploit but still concerning given the kernel's privileged execution context. The flaw specifically affects systems utilizing the maple tree implementation for register caching, which is common in embedded systems and device drivers requiring efficient register management.
The vulnerability's detection limitations highlight the inadequacy of existing test coverage, as the KUnit test suite only validates scenarios starting at register address zero, where mas.index equals zero. This testing gap allowed the bug to persist undetected since the normal operation path did not trigger the out-of-bounds condition. The fix requires correcting the indexing calculation to properly account for relative offsets within cache blocks rather than absolute register addresses. This remediation aligns with established security practices for memory safety and follows the CWE-129 principle of ensuring proper input validation and array bounds checking. Organizations should prioritize updating their kernel versions to address this vulnerability and implement monitoring for potential exploitation attempts, particularly in embedded systems where register caching is heavily utilized.
This vulnerability demonstrates the complexity of kernel memory management systems and the critical importance of thorough testing across all operational scenarios. The issue connects to broader ATT&CK techniques related to privilege escalation and kernel exploitation, emphasizing that seemingly minor indexing errors in kernel code can have significant security implications. The fix serves as a reminder of the necessity for comprehensive testing methodologies that cover edge cases and boundary conditions in security-critical subsystems.