https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-02T19:34:10.268338+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2026-06030 bdu:2026-06030 2026-10-02T19:34:10.274385+00:00 bdu:2026-06030 https://cve.radiocsirt.org/vuln/bell-cve-2023-53341 BELL-CVE-2023-53341 2026-10-02T19:34:10.274421+00:00

Affected: Alpaquita:stream: linux-lts

 https://cve.radiocsirt.org/vuln/euvd-2026-311988 EUVD-2026-311988 2026-10-02T19:34:10.274447+00:00 EUVD-2026-311988 https://cve.radiocsirt.org/vuln/fkie_cve-2023-53341 fkie_cve-2023-53341 2026-10-02T19:34:10.274461+00:00

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

 https://cve.radiocsirt.org/vuln/ghsa-h68c-38x6-5x45 GHSA-h68c-38x6-5x45 2026-10-02T19:34:10.274495+00:00

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

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53341 UBUNTU-CVE-2023-53341 2026-10-02T19:34:10.274518+00:00

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 78 more

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

 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2087 WID-SEC-W-2025-2087 — Linux Kernel: Mehrere Schwachstellen 2026-10-02T19:34:10.274635+00:00

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.