<?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 13:40:12 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-06483</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-06483</link>
      <description>bdu:2025-06483</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-06483</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-47809</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-47809</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-2024-47809</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0088 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0088</link>
      <description>certfr-2025-avi-0088</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0088</guid>
    </item>
    <item>
      <title>cnvd-2025-04164</title>
      <link>https://cve.radiocsirt.org/vuln/cnvd-2025-04164</link>
      <description>cnvd-2025-04164</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cnvd-2025-04164</guid>
    </item>
    <item>
      <title>EUVD-2026-364452</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-364452</link>
      <description>EUVD-2026-364452</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-364452</guid>
    </item>
    <item>
      <title>fkie_cve-2024-47809</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-47809</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;dlm: fix possible lkb_resource null dereference&lt;/p&gt;
&lt;p&gt;This patch fixes a possible null pointer dereference when this function is
called from request_lock() as lkb-&amp;gt;lkb_resource is not assigned yet,
only after validate_lock_args() by calling attach_lkb(). Another issue
is that a resource name could be a non printable bytearray and we cannot
assume to be ASCII coded.&lt;/p&gt;
&lt;p&gt;The log functionality is probably never being hit when DLM is used in
normal way and no debug logging is enabled. The null pointer dereference
can only occur on a new created lkb that does not have the resource
assigned yet, it probably never hits the null pointer dereference but we
should be sure that other changes might not change this behaviour and we
actually can hit the mentioned null pointer dereference.&lt;/p&gt;
&lt;p&gt;In this patch we just drop the printout of the resource name, the lkb id
is enough to make a possible connection to a resource name if this
exists.&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;dlm: fix possible lkb_resource null dereference&lt;/p&gt;
&lt;p&gt;This patch fixes a possible null pointer dereference when this function is
called from request_lock() as lkb-&amp;gt;lkb_resource is not assigned yet,
only after validate_lock_args() by calling attach_lkb(). Another issue
is that a resource name could be a non printable bytearray and we cannot
assume to be ASCII coded.&lt;/p&gt;
&lt;p&gt;The log functionality is probably never being hit when DLM is used in
normal way and no debug logging is enabled. The null pointer dereference
can only occur on a new created lkb that does not have the resource
assigned yet, it probably never hits the null pointer dereference but we
should be sure that other changes might not change this behaviour and we
actually can hit the mentioned null pointer dereference.&lt;/p&gt;
&lt;p&gt;In this patch we just drop the printout of the resource name, the lkb id
is enough to make a possible connection to a resource name if this
exists.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-47809</guid>
    </item>
    <item>
      <title>GHSA-9fhm-w5m6-rqv5</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-9fhm-w5m6-rqv5</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;dlm: fix possible lkb_resource null dereference&lt;/p&gt;
&lt;p&gt;This patch fixes a possible null pointer dereference when this function is
called from request_lock() as lkb-&amp;gt;lkb_resource is not assigned yet,
only after validate_lock_args() by calling attach_lkb(). Another issue
is that a resource name could be a non printable bytearray and we cannot
assume to be ASCII coded.&lt;/p&gt;
&lt;p&gt;The log functionality is probably never being hit when DLM is used in
normal way and no debug logging is enabled. The null pointer dereference
can only occur on a new created lkb that does not have the resource
assigned yet, it probably never hits the null pointer dereference but we
should be sure that other changes might not change this behaviour and we
actually can hit the mentioned null pointer dereference.&lt;/p&gt;
&lt;p&gt;In this patch we just drop the printout of the resource name, the lkb id
is enough to make a possible connection to a resource name if this
exists.&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;dlm: fix possible lkb_resource null dereference&lt;/p&gt;
&lt;p&gt;This patch fixes a possible null pointer dereference when this function is
called from request_lock() as lkb-&amp;gt;lkb_resource is not assigned yet,
only after validate_lock_args() by calling attach_lkb(). Another issue
is that a resource name could be a non printable bytearray and we cannot
assume to be ASCII coded.&lt;/p&gt;
&lt;p&gt;The log functionality is probably never being hit when DLM is used in
normal way and no debug logging is enabled. The null pointer dereference
can only occur on a new created lkb that does not have the resource
assigned yet, it probably never hits the null pointer dereference but we
should be sure that other changes might not change this behaviour and we
actually can hit the mentioned null pointer dereference.&lt;/p&gt;
&lt;p&gt;In this patch we just drop the printout of the resource name, the lkb id
is enough to make a possible connection to a resource name if this
exists.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-9fhm-w5m6-rqv5</guid>
    </item>
    <item>
      <title>ICSA-26-209-04 — Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-26-209-04</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-26-209-04</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-47809 — dlm: fix possible lkb_resource null dereference</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-47809</link>
      <description>msrc_CVE-2024-47809</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-47809</guid>
    </item>
    <item>
      <title>OESA-2025-1286 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1286</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;IORING_OP_READ did not correctly consume the provided buffer list when
read i/o returned &amp;amp;lt; 0 (except for -EAGAIN and -EIOCBQUEUED return).
This can lead to a potential use-after-free when the completion via
io_rw_done runs at separate context.(CVE-2023-52926)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;f2fs: fix to shrink read extent node in batches&lt;/p&gt;
&lt;p&gt;We use rwlock to protect core structure data of extent tree during
its shrink, however, if there is a huge number of extent nodes in
extent tree, during shrink of extent tree, it may hold rwlock for
a very long time, which may trigger kernel hang issue.&lt;/p&gt;
&lt;p&gt;This patch fixes to shrink read extent node in batches, so that,
critical region of the rwlock can be shrunk to avoid its extreme
long time hold.(CVE-2024-41935)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;dma-debug: fix a possible deadlock on radix_lock&lt;/p&gt;
&lt;p&gt;radix_lock() shouldn&amp;amp;apos;t be held while holding dma_hash_entry[idx].lock
otherwise, there&amp;amp;apos;s a possible deadlock scenario when
dma debug API is called holding rq_lock():&lt;/p&gt;
&lt;p&gt;CPU0                   CPU1                       CPU2
dma_free_attrs()
check_unmap()          add_dma_entry()            __schedule() //out
                                                  (A) rq_lock()
get_hash_bucket()
(A) dma_entry_hash…&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;IORING_OP_READ did not correctly consume the provided buffer list when
read i/o returned &amp;amp;lt; 0 (except for -EAGAIN and -EIOCBQUEUED return).
This can lead to a potential use-after-free when the completion via
io_rw_done runs at separate context.(CVE-2023-52926)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;f2fs: fix to shrink read extent node in batches&lt;/p&gt;
&lt;p&gt;We use rwlock to protect core structure data of extent tree during
its shrink, however, if there is a huge number of extent nodes in
extent tree, during shrink of extent tree, it may hold rwlock for
a very long time, which may trigger kernel hang issue.&lt;/p&gt;
&lt;p&gt;This patch fixes to shrink read extent node in batches, so that,
critical region of the rwlock can be shrunk to avoid its extreme
long time hold.(CVE-2024-41935)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;dma-debug: fix a possible deadlock on radix_lock&lt;/p&gt;
&lt;p&gt;radix_lock() shouldn&amp;amp;apos;t be held while holding dma_hash_entry[idx].lock
otherwise, there&amp;amp;apos;s a possible deadlock scenario when
dma debug API is called holding rq_lock():&lt;/p&gt;
&lt;p&gt;CPU0                   CPU1                       CPU2
dma_free_attrs()
check_unmap()          add_dma_entry()            __schedule() //out
                                                  (A) rq_lock()
get_hash_bucket()
(A) dma_entry_hash…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1286</guid>
    </item>
    <item>
      <title>SSA-019113 — SSA-019113: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP V3.1.6</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-019113</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-019113</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:0289-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:0289-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:0289-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-47809</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-47809</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 197 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb-&amp;gt;lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference. In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.&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 197 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb-&amp;gt;lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference. In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-47809</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-0047 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0047</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen und weitere nicht spezifizierte Angriffe zu starten.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen und weitere nicht spezifizierte Angriffe zu starten.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0047</guid>
    </item>
  </channel>
</rss>
