<?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>Fri, 02 Oct 2026 20:14:23 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-16403</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-16403</link>
      <description>bdu:2025-16403</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-16403</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-40071</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-40071</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-40071</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0941 — De multiples vulnérabilités ont été découvertes dans les produits Microsoft. Elles permettent à un attaquant de provoqu…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0941</link>
      <description>certfr-2025-avi-0941</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0941</guid>
    </item>
    <item>
      <title>EUVD-2026-320883</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320883</link>
      <description>EUVD-2026-320883</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320883</guid>
    </item>
    <item>
      <title>fkie_cve-2025-40071</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-40071</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tty: n_gsm: Don&amp;#39;t block input queue by waiting MSC&lt;/p&gt;
&lt;p&gt;Currently gsm_queue() processes incoming frames and when opening
a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().
If basic mode is used it calls gsm_modem_upd_via_msc() and it
cannot block the input queue by waiting the response to come
into the same input queue.&lt;/p&gt;
&lt;p&gt;Instead allow sending Modem Status Command without waiting for remote
end to respond. Define a new function gsm_modem_send_initial_msc()
for this purpose. As MSC is only valid for basic encoding, it does
not do anything for advanced or when convergence layer type 2 is used.&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;tty: n_gsm: Don&amp;#39;t block input queue by waiting MSC&lt;/p&gt;
&lt;p&gt;Currently gsm_queue() processes incoming frames and when opening
a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().
If basic mode is used it calls gsm_modem_upd_via_msc() and it
cannot block the input queue by waiting the response to come
into the same input queue.&lt;/p&gt;
&lt;p&gt;Instead allow sending Modem Status Command without waiting for remote
end to respond. Define a new function gsm_modem_send_initial_msc()
for this purpose. As MSC is only valid for basic encoding, it does
not do anything for advanced or when convergence layer type 2 is used.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-40071</guid>
    </item>
    <item>
      <title>GHSA-xj3g-qjx7-6cfm</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-xj3g-qjx7-6cfm</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tty: n_gsm: Don&amp;#39;t block input queue by waiting MSC&lt;/p&gt;
&lt;p&gt;Currently gsm_queue() processes incoming frames and when opening
a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().
If basic mode is used it calls gsm_modem_upd_via_msc() and it
cannot block the input queue by waiting the response to come
into the same input queue.&lt;/p&gt;
&lt;p&gt;Instead allow sending Modem Status Command without waiting for remote
end to respond. Define a new function gsm_modem_send_initial_msc()
for this purpose. As MSC is only valid for basic encoding, it does
not do anything for advanced or when convergence layer type 2 is used.&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;tty: n_gsm: Don&amp;#39;t block input queue by waiting MSC&lt;/p&gt;
&lt;p&gt;Currently gsm_queue() processes incoming frames and when opening
a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().
If basic mode is used it calls gsm_modem_upd_via_msc() and it
cannot block the input queue by waiting the response to come
into the same input queue.&lt;/p&gt;
&lt;p&gt;Instead allow sending Modem Status Command without waiting for remote
end to respond. Define a new function gsm_modem_send_initial_msc()
for this purpose. As MSC is only valid for basic encoding, it does
not do anything for advanced or when convergence layer type 2 is used.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-xj3g-qjx7-6cfm</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-40071 — tty: n_gsm: Don't block input queue by waiting MSC</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-40071</link>
      <description>msrc_CVE-2025-40071</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-40071</guid>
    </item>
    <item>
      <title>OESA-2025-2633 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-2633</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst:   Some memory may share the same node as a CPU, and others are provided as  memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a  first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an  index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat:  UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y  index 512 is out of range for type  unsigned long[512]   [...]  Call Trace:   dump_stack   __ubsan_handle_out_of_bounds   load_microcode_amd   request_microcode_amd   reload_store   kernfs_fop_write_iter   vfs_write   ksys_write   do_syscall_64   entry_SYSCALL_64_after…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst:   Some memory may share the same node as a CPU, and others are provided as  memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a  first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an  index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat:  UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y  index 512 is out of range for type  unsigned long[512]   [...]  Call Trace:   dump_stack   __ubsan_handle_out_of_bounds   load_microcode_amd   request_microcode_amd   reload_store   kernfs_fop_write_iter   vfs_write   ksys_write   do_syscall_64   entry_SYSCALL_64_after…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-2633</guid>
    </item>
    <item>
      <title>openSUSE-SU-2025:15702-1 — kernel-devel-6.17.7-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2025:15702-1</link>
      <description>&lt;p&gt;kernel-devel-6.17.7-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-6.17.7-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2025:15702-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:21040-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:21040-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:21040-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-40071</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40071</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 176 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Don&amp;#39;t block input queue by waiting MSC Currently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue. Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 176 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Don&amp;#39;t block input queue by waiting MSC Currently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue. Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40071</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2431 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2431</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um beliebigen Code auszuführen, privilegierten Zugriff zu erlangen, sensible Informationen zu stehlen oder betroffene Systeme funktionsunfähig zu machen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um beliebigen Code auszuführen, privilegierten Zugriff zu erlangen, sensible Informationen zu stehlen oder betroffene Systeme funktionsunfähig zu machen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2431</guid>
    </item>
  </channel>
</rss>
