A vulnerability was determined in Cudy TR1200 R46-2.4.15-20250721-164017. Impacted is the function action_ipsec_conn of the file /usr/bin/lib/lua/luci/controller/ipsec.lua. Executing a manipulation can lead to command injection. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized. Upgrading the affected component is advised. The vendor explains, that "some other customer has reported this to us before. And we have fixed this."

A security vulnerability has been detected in Cudy TR1200 1.16.3-20230804-164635. Impacted is an unknown function of the file /cgi-bin/luci/admin/network/wireless/config/ of the component Wireless Settings Page. Such manipulation of the argument SSID leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

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