Bug 2396134 (CVE-2023-53341) - CVE-2023-53341 kernel: of/fdt: run soc memory setup when early_init_dt_scan_memory fails
Summary: CVE-2023-53341 kernel: of/fdt: run soc memory setup when early_init_dt_scan_m...
Keywords:
Status: NEW
Alias: CVE-2023-53341
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-09-17 15:03 UTC by OSIDB Bzimport
Modified: 2025-09-17 18:26 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2025-09-17 15:03:19 UTC
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".


Note You need to log in before you can comment on or make changes to this bug.