https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 21:55:16 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-23352 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-23352 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0376 certfr-2026-avi-0376 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0376 https://cve.radiocsirt.org/vuln/euvd-2026-320955 EUVD-2026-320955 https://cve.radiocsirt.org/vuln/euvd-2026-320955 https://cve.radiocsirt.org/vuln/fkie_cve-2026-23352 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>x86/efi: defer freeing of boot services memory</p> <p>efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late().</p> <p>There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area().</p> <p>More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete.</p> <p>Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM.</p> <p>If the freed memory resides in the areas that memory map for them is still uninitialized, they won&#39;t be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages.</p> <p>Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map.</p> <p>Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that&#39;s undesirable late in boot when there is concurrency.</p> <p>More robust approach is to only defer freeing of the EFI boot services memory.</p> <p>Split efi_free_boot_services() in two. First ef…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>x86/efi: defer freeing of boot services memory</p> <p>efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late().</p> <p>There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area().</p> <p>More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete.</p> <p>Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM.</p> <p>If the freed memory resides in the areas that memory map for them is still uninitialized, they won&#39;t be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages.</p> <p>Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map.</p> <p>Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that&#39;s undesirable late in boot when there is concurrency.</p> <p>More robust approach is to only defer freeing of the EFI boot services memory.</p> <p>Split efi_free_boot_services() in two. First ef…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-23352 https://cve.radiocsirt.org/vuln/ghsa-3ggx-9863-fxcm <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>x86/efi: defer freeing of boot services memory</p> <p>efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late().</p> <p>There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area().</p> <p>More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete.</p> <p>Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM.</p> <p>If the freed memory resides in the areas that memory map for them is still uninitialized, they won&#39;t be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages.</p> <p>Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map.</p> <p>Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that&#39;s undesirable late in boot when there is concurrency.</p> <p>More robust approach is to only defer freeing of the EFI boot services memory.</p> <p>Split efi_free_boot_services() in two. First ef…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>x86/efi: defer freeing of boot services memory</p> <p>efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late().</p> <p>There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area().</p> <p>More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete.</p> <p>Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM.</p> <p>If the freed memory resides in the areas that memory map for them is still uninitialized, they won&#39;t be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages.</p> <p>Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map.</p> <p>Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that&#39;s undesirable late in boot when there is concurrency.</p> <p>More robust approach is to only defer freeing of the EFI boot services memory.</p> <p>Split efi_free_boot_services() in two. First ef…</p> https://cve.radiocsirt.org/vuln/ghsa-3ggx-9863-fxcm https://cve.radiocsirt.org/vuln/msrc_cve-2026-23352 msrc_CVE-2026-23352 https://cve.radiocsirt.org/vuln/msrc_cve-2026-23352 https://cve.radiocsirt.org/vuln/oesa-2026-1831 <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>A vulnerability exists in the RDMA/umad component of the Linux kernel when processing user-space data. The ib_umad_write function calculates data_len based on user-controlled count and MAD header sizes. When a mismatched user MAD header size and RMPP header length are provided, data_len can become negative and be passed to the ib_create_send_mad() function. This can cause subsequent padding calculations to exceed the segment size, ultimately triggering an out-of-bounds memory write (memset) in the alloc_send_rmpp_list() function. An attacker could potentially exploit this vulnerability to cause kernel memory corruption, affecting system stability and confidentiality.(CVE-2026-23243)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>x86/efi: defer freeing of boot services memory</p> <p>efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late().</p> <p>There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area().</p> <p>More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete.</p> <p>Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM.</p> <p>I…</p> <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>A vulnerability exists in the RDMA/umad component of the Linux kernel when processing user-space data. The ib_umad_write function calculates data_len based on user-controlled count and MAD header sizes. When a mismatched user MAD header size and RMPP header length are provided, data_len can become negative and be passed to the ib_create_send_mad() function. This can cause subsequent padding calculations to exceed the segment size, ultimately triggering an out-of-bounds memory write (memset) in the alloc_send_rmpp_list() function. An attacker could potentially exploit this vulnerability to cause kernel memory corruption, affecting system stability and confidentiality.(CVE-2026-23243)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>x86/efi: defer freeing of boot services memory</p> <p>efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late().</p> <p>There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area().</p> <p>More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete.</p> <p>Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM.</p> <p>I…</p> https://cve.radiocsirt.org/vuln/oesa-2026-1831 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23352 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 232 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: x86/efi: defer freeing of boot services memory efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won&#39;t be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that&#39;s undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_bo…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 232 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: x86/efi: defer freeing of boot services memory efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won&#39;t be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that&#39;s undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_bo…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23352 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0861 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, weitere nicht spezifizierte Auswirkungen zu verursachen und potentiell Code auszuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, weitere nicht spezifizierte Auswirkungen zu verursachen und potentiell Code auszuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0861