CVE-2023-53341
published 2025-09-17CVE-2023-53341: 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…
PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.19%
8.6th percentile
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".
Affected
11 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.7-1 (bookworm) | linux 6.1.7-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 1f012283e9360fb4007308f04cfaeb205e34b684 < 04836fc5b720dfa32ff781383d84f63019abf9b9 | 04836fc5b720dfa32ff781383d84f63019abf9b9 |
| linux | linux | >= 1f012283e9360fb4007308f04cfaeb205e34b684 < c4849f18185fd4e93b04cd45552f8d68c0240e21 | c4849f18185fd4e93b04cd45552f8d68c0240e21 |
| linux | linux | >= 1f012283e9360fb4007308f04cfaeb205e34b684 < 2a12187d5853d9fd5102278cecef7dac7c8ce7ea | 2a12187d5853d9fd5102278cecef7dac7c8ce7ea |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.1.7-1 | 6.1.7-1 |
| linux | linux_kernel | >= 0 < 6.1.7-1 | 6.1.7-1 |
| linux | linux_kernel | >= 0 < 6.1.7-1 | 6.1.7-1 |
| linux | linux_kernel | >= 5.17 < 6.0.19 | 6.0.19 |
| linux | linux_kernel | >= 6.1 < 6.1.5 | 6.1.5 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: of/fdt: run soc memory setup when early_init_dt_scan_memory fails
vendor_redhat·2025-09-17·CVSS 5.5
CVE-2023-53341 [MEDIUM] kernel: of/fdt: run soc memory setup when early_init_dt_scan_memory fails
kernel: of/fdt: run soc memory setup when early_init_dt_scan_memory fails
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
Debian
CVE-2023-53341: linux - In the Linux kernel, the following vulnerability has been resolved: of/fdt: run...
vendor_debian·2023·CVSS 5.5
CVE-2023-53341 [MEDIUM] CVE-2023-53341: linux - In the Linux kernel, the following vulnerability has been resolved: of/fdt: run...
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 mem
GHSA
GHSA-h68c-38x6-5x45: 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
ghsa_unreviewed·2025-09-17
CVE-2023-53341 [MEDIUM] CWE-908 GHSA-h68c-38x6-5x45: 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
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
OSV
CVE-2023-53341: 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 be
osv·2025-09-17·CVSS 5.5
CVE-2023-53341 [MEDIUM] CVE-2023-53341: 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 be
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 mem
No detection rules found.
No public exploits indexed.
2025-09-17
Published