<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 04 Oct 2026 07:34:26 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-03744</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-03744</link>
      <description>bdu:2025-03744</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-03744</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-21872</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-21872</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2025-21872</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0463 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de p…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0463</link>
      <description>certfr-2025-avi-0463</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0463</guid>
    </item>
    <item>
      <title>EUVD-2026-314073</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-314073</link>
      <description>EUVD-2026-314073</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-314073</guid>
    </item>
    <item>
      <title>fkie_cve-2025-21872</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-21872</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;efi: Don&amp;#39;t map the entire mokvar table to determine its size&lt;/p&gt;
&lt;p&gt;Currently, when validating the mokvar table, we (re)map the entire table
on each iteration of the loop, adding space as we discover new entries.
If the table grows over a certain size, this fails due to limitations of
early_memmap(), and we get a failure and traceback:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
  WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220
  ...
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ? __early_ioremap+0xef/0x220
   ? __warn.cold+0x93/0xfa
   ? __early_ioremap+0xef/0x220
   ? report_bug+0xff/0x140
   ? early_fixup_exception+0x5d/0xb0
   ? early_idt_handler_common+0x2f/0x3a
   ? __early_ioremap+0xef/0x220
   ? efi_mokvar_table_init+0xce/0x1d0
   ? setup_arch+0x864/0xc10
   ? start_kernel+0x6b/0xa10
   ? x86_64_start_reservations+0x24/0x30
   ? x86_64_start_kernel+0xed/0xf0
   ? common_startup_64+0x13e/0x141
   &amp;lt;/TASK&amp;gt;
  ---[ end trace 0000000000000000 ]---
  mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.&lt;/p&gt;
&lt;p&gt;Mapping the entire structure isn&amp;#39;t actually necessary, as we don&amp;#39;t ever
need more than one entry header mapped at once.&lt;/p&gt;
&lt;p&gt;Changes efi_mokvar_table_init() to only map each entry header, not the
entire table, when determining the table size.  Since we&amp;#39;re not mapping
any data past the variable name, it also changes the code to enforce
that each variable name is NUL terminated, rather than at…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;efi: Don&amp;#39;t map the entire mokvar table to determine its size&lt;/p&gt;
&lt;p&gt;Currently, when validating the mokvar table, we (re)map the entire table
on each iteration of the loop, adding space as we discover new entries.
If the table grows over a certain size, this fails due to limitations of
early_memmap(), and we get a failure and traceback:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
  WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220
  ...
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ? __early_ioremap+0xef/0x220
   ? __warn.cold+0x93/0xfa
   ? __early_ioremap+0xef/0x220
   ? report_bug+0xff/0x140
   ? early_fixup_exception+0x5d/0xb0
   ? early_idt_handler_common+0x2f/0x3a
   ? __early_ioremap+0xef/0x220
   ? efi_mokvar_table_init+0xce/0x1d0
   ? setup_arch+0x864/0xc10
   ? start_kernel+0x6b/0xa10
   ? x86_64_start_reservations+0x24/0x30
   ? x86_64_start_kernel+0xed/0xf0
   ? common_startup_64+0x13e/0x141
   &amp;lt;/TASK&amp;gt;
  ---[ end trace 0000000000000000 ]---
  mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.&lt;/p&gt;
&lt;p&gt;Mapping the entire structure isn&amp;#39;t actually necessary, as we don&amp;#39;t ever
need more than one entry header mapped at once.&lt;/p&gt;
&lt;p&gt;Changes efi_mokvar_table_init() to only map each entry header, not the
entire table, when determining the table size.  Since we&amp;#39;re not mapping
any data past the variable name, it also changes the code to enforce
that each variable name is NUL terminated, rather than at…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-21872</guid>
    </item>
    <item>
      <title>GHSA-9pcq-fqff-43qc</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-9pcq-fqff-43qc</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;efi: Don&amp;#39;t map the entire mokvar table to determine its size&lt;/p&gt;
&lt;p&gt;Currently, when validating the mokvar table, we (re)map the entire table
on each iteration of the loop, adding space as we discover new entries.
If the table grows over a certain size, this fails due to limitations of
early_memmap(), and we get a failure and traceback:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
  WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220
  ...
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ? __early_ioremap+0xef/0x220
   ? __warn.cold+0x93/0xfa
   ? __early_ioremap+0xef/0x220
   ? report_bug+0xff/0x140
   ? early_fixup_exception+0x5d/0xb0
   ? early_idt_handler_common+0x2f/0x3a
   ? __early_ioremap+0xef/0x220
   ? efi_mokvar_table_init+0xce/0x1d0
   ? setup_arch+0x864/0xc10
   ? start_kernel+0x6b/0xa10
   ? x86_64_start_reservations+0x24/0x30
   ? x86_64_start_kernel+0xed/0xf0
   ? common_startup_64+0x13e/0x141
   &amp;lt;/TASK&amp;gt;
  ---[ end trace 0000000000000000 ]---
  mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.&lt;/p&gt;
&lt;p&gt;Mapping the entire structure isn&amp;#39;t actually necessary, as we don&amp;#39;t ever
need more than one entry header mapped at once.&lt;/p&gt;
&lt;p&gt;Changes efi_mokvar_table_init() to only map each entry header, not the
entire table, when determining the table size.  Since we&amp;#39;re not mapping
any data past the variable name, it also changes the code to enforce
that each variable name is NUL terminated, rather than at…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;efi: Don&amp;#39;t map the entire mokvar table to determine its size&lt;/p&gt;
&lt;p&gt;Currently, when validating the mokvar table, we (re)map the entire table
on each iteration of the loop, adding space as we discover new entries.
If the table grows over a certain size, this fails due to limitations of
early_memmap(), and we get a failure and traceback:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
  WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220
  ...
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ? __early_ioremap+0xef/0x220
   ? __warn.cold+0x93/0xfa
   ? __early_ioremap+0xef/0x220
   ? report_bug+0xff/0x140
   ? early_fixup_exception+0x5d/0xb0
   ? early_idt_handler_common+0x2f/0x3a
   ? __early_ioremap+0xef/0x220
   ? efi_mokvar_table_init+0xce/0x1d0
   ? setup_arch+0x864/0xc10
   ? start_kernel+0x6b/0xa10
   ? x86_64_start_reservations+0x24/0x30
   ? x86_64_start_kernel+0xed/0xf0
   ? common_startup_64+0x13e/0x141
   &amp;lt;/TASK&amp;gt;
  ---[ end trace 0000000000000000 ]---
  mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.&lt;/p&gt;
&lt;p&gt;Mapping the entire structure isn&amp;#39;t actually necessary, as we don&amp;#39;t ever
need more than one entry header mapped at once.&lt;/p&gt;
&lt;p&gt;Changes efi_mokvar_table_init() to only map each entry header, not the
entire table, when determining the table size.  Since we&amp;#39;re not mapping
any data past the variable name, it also changes the code to enforce
that each variable name is NUL terminated, rather than at…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-9pcq-fqff-43qc</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-21872 — efi: Don't map the entire mokvar table to determine its size</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-21872</link>
      <description>msrc_CVE-2025-21872</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-21872</guid>
    </item>
    <item>
      <title>OESA-2025-1625 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1625</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;xen: Fix the issue of resource not being properly released in xenbus_dev_probe()&lt;/p&gt;
&lt;p&gt;This patch fixes an issue in the function xenbus_dev_probe(). In the
xenbus_dev_probe() function, within the if (err) branch at line 313, the
program incorrectly returns err directly without releasing the resources
allocated by err = drv-&amp;amp;gt;probe(dev, id). As the return value is non-zero,
the upper layers assume the processing logic has failed. However, the probe
operation was performed earlier without a corresponding remove operation.
Since the probe actually allocates resources, failing to perform the remove
operation could lead to problems.&lt;/p&gt;
&lt;p&gt;To fix this issue, we followed the resource release logic of the
xenbus_dev_remove() function by adding a new block fail_remove before the
fail_put block. After entering the branch if (err) at line 313, the
function will use a goto statement to jump to the fail_remove block,
ensuring that the previously acquired resources are correctly released,
thus preventing the reference count leak.&lt;/p&gt;
&lt;p&gt;This bug was identified by an experimental static analysis tool developed
by our team. The tool specializes in analyzing reference count operations
and detecting potential issues where resources are not properly managed.
In this case, the tool flagged the missing release operation as a
potential problem, which led to the developm…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;xen: Fix the issue of resource not being properly released in xenbus_dev_probe()&lt;/p&gt;
&lt;p&gt;This patch fixes an issue in the function xenbus_dev_probe(). In the
xenbus_dev_probe() function, within the if (err) branch at line 313, the
program incorrectly returns err directly without releasing the resources
allocated by err = drv-&amp;amp;gt;probe(dev, id). As the return value is non-zero,
the upper layers assume the processing logic has failed. However, the probe
operation was performed earlier without a corresponding remove operation.
Since the probe actually allocates resources, failing to perform the remove
operation could lead to problems.&lt;/p&gt;
&lt;p&gt;To fix this issue, we followed the resource release logic of the
xenbus_dev_remove() function by adding a new block fail_remove before the
fail_put block. After entering the branch if (err) at line 313, the
function will use a goto statement to jump to the fail_remove block,
ensuring that the previously acquired resources are correctly released,
thus preventing the reference count leak.&lt;/p&gt;
&lt;p&gt;This bug was identified by an experimental static analysis tool developed
by our team. The tool specializes in analyzing reference count operations
and detecting potential issues where resources are not properly managed.
In this case, the tool flagged the missing release operation as a
potential problem, which led to the developm…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1625</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:02853-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:02853-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2025:02853-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-21872</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21872</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 202 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: efi: Don&amp;#39;t map the entire mokvar table to determine its size Currently, when validating the mokvar table, we (re)map the entire table on each iteration of the loop, adding space as we discover new entries. If the table grows over a certain size, this fails due to limitations of early_memmap(), and we get a failure and traceback:   ------------[ cut here ]------------   WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220   ...   Call Trace:    &amp;lt;TASK&amp;gt;    ? __early_ioremap+0xef/0x220    ? __warn.cold+0x93/0xfa    ? __early_ioremap+0xef/0x220    ? report_bug+0xff/0x140    ? early_fixup_exception+0x5d/0xb0    ? early_idt_handler_common+0x2f/0x3a    ? __early_ioremap+0xef/0x220    ? efi_mokvar_table_init+0xce/0x1d0    ? setup_arch+0x864/0xc10    ? start_kernel+0x6b/0xa10    ? x86_64_start_reservations+0x24/0x30    ? x86_64_start_kernel+0xed/0xf0    ? common_startup_64+0x13e/0x141    &amp;lt;/TASK&amp;gt;   ---[ end trace 0000000000000000 ]---   mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187. Mapping the entire structure isn&amp;#39;t actually necessary, as we don&amp;#39;t ever need more than one entry header mapped at once. Changes efi_mokvar_table_init() to only map each entry header, not the entire table, when determining the table size.  Since we&amp;#39;re not mapping any data past the variable name, it also changes the code to enforce that each variable name is NUL terminated, rather than attempt…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 202 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: efi: Don&amp;#39;t map the entire mokvar table to determine its size Currently, when validating the mokvar table, we (re)map the entire table on each iteration of the loop, adding space as we discover new entries. If the table grows over a certain size, this fails due to limitations of early_memmap(), and we get a failure and traceback:   ------------[ cut here ]------------   WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220   ...   Call Trace:    &amp;lt;TASK&amp;gt;    ? __early_ioremap+0xef/0x220    ? __warn.cold+0x93/0xfa    ? __early_ioremap+0xef/0x220    ? report_bug+0xff/0x140    ? early_fixup_exception+0x5d/0xb0    ? early_idt_handler_common+0x2f/0x3a    ? __early_ioremap+0xef/0x220    ? efi_mokvar_table_init+0xce/0x1d0    ? setup_arch+0x864/0xc10    ? start_kernel+0x6b/0xa10    ? x86_64_start_reservations+0x24/0x30    ? x86_64_start_kernel+0xed/0xf0    ? common_startup_64+0x13e/0x141    &amp;lt;/TASK&amp;gt;   ---[ end trace 0000000000000000 ]---   mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187. Mapping the entire structure isn&amp;#39;t actually necessary, as we don&amp;#39;t ever need more than one entry header mapped at once. Changes efi_mokvar_table_init() to only map each entry header, not the entire table, when determining the table size.  Since we&amp;#39;re not mapping any data past the variable name, it also changes the code to enforce that each variable name is NUL terminated, rather than attempt…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21872</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-0649 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0649</link>
      <description>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht spezifizierte Effekte zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht spezifizierte Effekte zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0649</guid>
    </item>
  </channel>
</rss>
