CVE-2023-53341 in Linux
Summary
by MITRE • 09/17/2025
In the Linux kernel, the following vulnerability has been resolved:
of/fdt: run soc memory setup when early_init_dt_scan_memory fails
If memory has been found early_init_dt_scan_memory now returns 1. If it hasn't found any memory it will return 0, allowing other memory setup mechanisms to carry on.
Previously early_init_dt_scan_memory always returned 0 without distinguishing between any kind of memory setup being done or not. Any code path after the early_init_dt_scan memory call in the ramips plat_mem_setup code wouldn't be executed anymore. Making early_init_dt_scan_memory the only way to initialize the memory.
Some boards, including my mt7621 based Cudy X6 board, depend on memory initialization being done via the soc_info.mem_detect function pointer. Those wouldn't be able to obtain memory and panic the kernel during early bootup with the message "early_init_dt_alloc_memory_arch: Failed to allocate 12416 bytes align=0x40".
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 12/27/2025
This vulnerability exists within the linux kernel's device tree handling mechanism specifically affecting the memory initialization process during early boot phases. The issue stems from how the early_init_dt_scan_memory function behaves when processing memory information from device tree data. Prior to the fix, this function consistently returned zero regardless of whether memory setup had actually occurred, creating a critical path dependency that prevented alternative memory initialization methods from executing properly. The vulnerability impacts systems using the ramips platform where memory detection relies on specific function pointers like soc_info.mem_detect, which are bypassed when the device tree memory scanning fails to properly indicate memory availability.
The technical flaw manifests in the conditional logic of the device tree memory scanning process where the early_init_dt_scan_memory function fails to distinguish between successful memory detection and complete memory absence. When memory is successfully identified during early_init_dt_scan_memory execution, it should return 1 to signal that memory initialization has occurred, allowing subsequent memory setup mechanisms to proceed. However, when no memory is found, it should return 0 to indicate that alternative memory detection methods should be invoked. This distinction is crucial for platforms like the mt7621 based Cudy X6 board that depend on specific memory initialization sequences through soc_info.mem_detect function pointers, which are never executed when the early_init_dt_scan_memory function incorrectly signals memory availability through its return value.
The operational impact of this vulnerability is severe during early boot phases, particularly affecting embedded systems and router platforms that rely on specific memory initialization sequences. Systems experiencing this issue will panic during early boot with the error message "early_init_dt_alloc_memory_arch: Failed to allocate 12416 bytes align=0x40" indicating that memory allocation fails because the proper memory setup sequence was never completed. This affects devices using the ramips platform where the memory initialization code path depends on the soc_info.mem_detect function pointer, which becomes unreachable when early_init_dt_scan_memory incorrectly returns zero even when memory detection has occurred. The vulnerability essentially creates a boot-time deadlock where the kernel cannot properly initialize memory for subsequent operations, rendering affected devices non-functional.
The fix addresses this by implementing proper return value semantics in the early_init_dt_scan_memory function to differentiate between memory detection success and failure scenarios. This change ensures that when memory is successfully identified during device tree scanning, the function returns 1 to indicate that memory initialization has occurred, allowing other memory setup mechanisms to execute properly. Conversely, when no memory is found, it returns 0 to enable alternative initialization paths. This modification aligns with the principle of proper error handling and conditional execution flow control, preventing the premature termination of memory setup sequences. The solution follows established kernel development practices for device tree memory management and ensures compatibility with existing platform-specific memory initialization requirements.
This vulnerability maps to CWE-755 (Improper Handling of Exceptional Conditions) and CWE-252 (Unchecked Return Values) as it involves improper handling of memory detection results and failure to properly check return values from memory initialization functions. The attack surface is primarily limited to early boot phases of embedded systems, making it more of a denial-of-service vulnerability than an exploitable security flaw, though it can effectively prevent system operation entirely. From an ATT&CK perspective, this relates to T1490 (Inhibit System Recovery) through the boot process disruption, though it does not involve direct user interaction or privilege escalation. The vulnerability affects Linux kernel versions that implement the ramips platform memory initialization, particularly those using device tree-based memory detection with specific function pointer dependencies.