linux-cve-announce - CVE-2023-53341: of/fdt: run soc memory setup when early_init_dt_scan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025091718-CVE-2023-53341-896e@gregkh>
Date: Wed, 17 Sep 2025 16:56:40 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2023-53341: of/fdt: run soc memory setup when early_init_dt_scan_memory fails

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

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".

The Linux kernel CVE team has assigned CVE-2023-53341 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 5.17 with commit 1f012283e9360fb4007308f04cfaeb205e34b684 and fixed in 6.0.19 with commit 04836fc5b720dfa32ff781383d84f63019abf9b9
	Issue introduced in 5.17 with commit 1f012283e9360fb4007308f04cfaeb205e34b684 and fixed in 6.1.5 with commit c4849f18185fd4e93b04cd45552f8d68c0240e21
	Issue introduced in 5.17 with commit 1f012283e9360fb4007308f04cfaeb205e34b684 and fixed in 6.2 with commit 2a12187d5853d9fd5102278cecef7dac7c8ce7ea

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2023-53341
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	arch/mips/ralink/of.c
	drivers/of/fdt.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/04836fc5b720dfa32ff781383d84f63019abf9b9
	https://git.kernel.org/stable/c/c4849f18185fd4e93b04cd45552f8d68c0240e21
	https://git.kernel.org/stable/c/2a12187d5853d9fd5102278cecef7dac7c8ce7ea