<?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 12:25:00 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-15187</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-15187</link>
      <description>bdu:2025-15187</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-15187</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-38687</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-38687</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-38687</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0825 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0825</link>
      <description>certfr-2025-avi-0825</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0825</guid>
    </item>
    <item>
      <title>EUVD-2026-347149</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347149</link>
      <description>EUVD-2026-347149</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347149</guid>
    </item>
    <item>
      <title>fkie_cve-2025-38687</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-38687</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;comedi: fix race between polling and detaching&lt;/p&gt;
&lt;p&gt;syzbot reports a use-after-free in comedi in the below link, which is
due to comedi gladly removing the allocated async area even though poll
requests are still active on the wait_queue_head inside of it. This can
cause a use-after-free when the poll entries are later triggered or
removed, as the memory for the wait_queue_head has been freed.  We need
to check there are no tasks queued on any of the subdevices&amp;#39; wait queues
before allowing the device to be detached by the `COMEDI_DEVCONFIG`
ioctl.&lt;/p&gt;
&lt;p&gt;Tasks will read-lock `dev-&amp;gt;attach_lock` before adding themselves to the
subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl
handler by write-locking `dev-&amp;gt;attach_lock` before checking that all of
the subdevices are safe to be deleted.  This includes testing for any
sleepers on the subdevices&amp;#39; wait queues.  It remains locked until the
device has been detached.  This requires the `comedi_device_detach()`
function to be refactored slightly, moving the bulk of it into new
function `comedi_device_detach_locked()`.&lt;/p&gt;
&lt;p&gt;Note that the refactor of `comedi_device_detach()` results in
`comedi_device_cancel_all()` now being called while `dev-&amp;gt;attach_lock`
is write-locked, which wasn&amp;#39;t the case previously, but that does not
matter.&lt;/p&gt;
&lt;p&gt;Thanks to Jens Axboe for diagnosing the problem and co-developing this
patch.&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;comedi: fix race between polling and detaching&lt;/p&gt;
&lt;p&gt;syzbot reports a use-after-free in comedi in the below link, which is
due to comedi gladly removing the allocated async area even though poll
requests are still active on the wait_queue_head inside of it. This can
cause a use-after-free when the poll entries are later triggered or
removed, as the memory for the wait_queue_head has been freed.  We need
to check there are no tasks queued on any of the subdevices&amp;#39; wait queues
before allowing the device to be detached by the `COMEDI_DEVCONFIG`
ioctl.&lt;/p&gt;
&lt;p&gt;Tasks will read-lock `dev-&amp;gt;attach_lock` before adding themselves to the
subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl
handler by write-locking `dev-&amp;gt;attach_lock` before checking that all of
the subdevices are safe to be deleted.  This includes testing for any
sleepers on the subdevices&amp;#39; wait queues.  It remains locked until the
device has been detached.  This requires the `comedi_device_detach()`
function to be refactored slightly, moving the bulk of it into new
function `comedi_device_detach_locked()`.&lt;/p&gt;
&lt;p&gt;Note that the refactor of `comedi_device_detach()` results in
`comedi_device_cancel_all()` now being called while `dev-&amp;gt;attach_lock`
is write-locked, which wasn&amp;#39;t the case previously, but that does not
matter.&lt;/p&gt;
&lt;p&gt;Thanks to Jens Axboe for diagnosing the problem and co-developing this
patch.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-38687</guid>
    </item>
    <item>
      <title>GHSA-gmr8-hqwc-6phj</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gmr8-hqwc-6phj</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;comedi: fix race between polling and detaching&lt;/p&gt;
&lt;p&gt;syzbot reports a use-after-free in comedi in the below link, which is
due to comedi gladly removing the allocated async area even though poll
requests are still active on the wait_queue_head inside of it. This can
cause a use-after-free when the poll entries are later triggered or
removed, as the memory for the wait_queue_head has been freed.  We need
to check there are no tasks queued on any of the subdevices&amp;#39; wait queues
before allowing the device to be detached by the `COMEDI_DEVCONFIG`
ioctl.&lt;/p&gt;
&lt;p&gt;Tasks will read-lock `dev-&amp;gt;attach_lock` before adding themselves to the
subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl
handler by write-locking `dev-&amp;gt;attach_lock` before checking that all of
the subdevices are safe to be deleted.  This includes testing for any
sleepers on the subdevices&amp;#39; wait queues.  It remains locked until the
device has been detached.  This requires the `comedi_device_detach()`
function to be refactored slightly, moving the bulk of it into new
function `comedi_device_detach_locked()`.&lt;/p&gt;
&lt;p&gt;Note that the refactor of `comedi_device_detach()` results in
`comedi_device_cancel_all()` now being called while `dev-&amp;gt;attach_lock`
is write-locked, which wasn&amp;#39;t the case previously, but that does not
matter.&lt;/p&gt;
&lt;p&gt;Thanks to Jens Axboe for diagnosing the problem and co-developing this
patch.&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;comedi: fix race between polling and detaching&lt;/p&gt;
&lt;p&gt;syzbot reports a use-after-free in comedi in the below link, which is
due to comedi gladly removing the allocated async area even though poll
requests are still active on the wait_queue_head inside of it. This can
cause a use-after-free when the poll entries are later triggered or
removed, as the memory for the wait_queue_head has been freed.  We need
to check there are no tasks queued on any of the subdevices&amp;#39; wait queues
before allowing the device to be detached by the `COMEDI_DEVCONFIG`
ioctl.&lt;/p&gt;
&lt;p&gt;Tasks will read-lock `dev-&amp;gt;attach_lock` before adding themselves to the
subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl
handler by write-locking `dev-&amp;gt;attach_lock` before checking that all of
the subdevices are safe to be deleted.  This includes testing for any
sleepers on the subdevices&amp;#39; wait queues.  It remains locked until the
device has been detached.  This requires the `comedi_device_detach()`
function to be refactored slightly, moving the bulk of it into new
function `comedi_device_detach_locked()`.&lt;/p&gt;
&lt;p&gt;Note that the refactor of `comedi_device_detach()` results in
`comedi_device_cancel_all()` now being called while `dev-&amp;gt;attach_lock`
is write-locked, which wasn&amp;#39;t the case previously, but that does not
matter.&lt;/p&gt;
&lt;p&gt;Thanks to Jens Axboe for diagnosing the problem and co-developing this
patch.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gmr8-hqwc-6phj</guid>
    </item>
    <item>
      <title>ICSA-26-134-10 — Siemens SIMATIC</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-26-134-10</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amd/display: Check link_res-&amp;gt;hpo_dp_link_enc before using it&#13;
&#13;
[WHAT &amp;amp; HOW]&#13;
Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res&#13;
without initializing hpo_dp_link_enc and it is necessary to check for&#13;
null before dereferencing.&#13;
&#13;
This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs: relax assertions on failure to encode file handles&lt;/p&gt;
&lt;p&gt;Encoding file handles is usually performed by a filesystem &amp;gt;encode_fh()
method that may fail for various reasons.&lt;/p&gt;
&lt;p&gt;The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.&lt;/p&gt;
&lt;p&gt;There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when -&amp;gt;encode_fh() fails.
Relax those assertions because they are wrong.&lt;/p&gt;
&lt;p&gt;The second linked bug report states commit 16aac5ad1fa9 (&amp;#34;ovl: support
encoding non-decodable file handles&amp;#34;) in v6.6 as the regressing commit,
but this is not accurate.&lt;/p&gt;
&lt;p&gt;The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.&lt;/p&gt;
&lt;p&gt;Triggering this assertion was always possible with other filesystems and
other reasons of -&amp;gt;encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlay…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amd/display: Check link_res-&amp;gt;hpo_dp_link_enc before using it&#13;
&#13;
[WHAT &amp;amp; HOW]&#13;
Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res&#13;
without initializing hpo_dp_link_enc and it is necessary to check for&#13;
null before dereferencing.&#13;
&#13;
This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs: relax assertions on failure to encode file handles&lt;/p&gt;
&lt;p&gt;Encoding file handles is usually performed by a filesystem &amp;gt;encode_fh()
method that may fail for various reasons.&lt;/p&gt;
&lt;p&gt;The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.&lt;/p&gt;
&lt;p&gt;There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when -&amp;gt;encode_fh() fails.
Relax those assertions because they are wrong.&lt;/p&gt;
&lt;p&gt;The second linked bug report states commit 16aac5ad1fa9 (&amp;#34;ovl: support
encoding non-decodable file handles&amp;#34;) in v6.6 as the regressing commit,
but this is not accurate.&lt;/p&gt;
&lt;p&gt;The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.&lt;/p&gt;
&lt;p&gt;Triggering this assertion was always possible with other filesystems and
other reasons of -&amp;gt;encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlay…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-26-134-10</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-38687 — comedi: fix race between polling and detaching</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-38687</link>
      <description>msrc_CVE-2025-38687</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-38687</guid>
    </item>
    <item>
      <title>NCSC-2026-0147 — Kwetsbaarheden verholpen in Siemens-producten</title>
      <link>https://cve.radiocsirt.org/vuln/ncsc-2026-0147</link>
      <description>NCSC-2026-0147</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ncsc-2026-0147</guid>
    </item>
    <item>
      <title>OESA-2025-2268 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-2268</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:&lt;/p&gt;
&lt;p&gt;rapidio: fix an API misues when rio_add_net() fails&lt;/p&gt;
&lt;p&gt;rio_add_net() calls device_register() and fails when device_register()
fails.  Thus, put_device() should be used rather than kfree().  Add
&amp;amp;quot;mport-&amp;amp;gt;net = NULL;&amp;amp;quot; to avoid a use after free issue.(CVE-2025-21934)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;cifs: Fix integer overflow while processing closetimeo mount option&lt;/p&gt;
&lt;p&gt;User-provided mount parameter closetimeo of type u32 is intended to have
an upper limit, but before it is validated, the value is converted from
seconds to jiffies which can lead to an integer overflow.&lt;/p&gt;
&lt;p&gt;Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21962)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ksmbd: fix use-after-free in ksmbd_free_work_struct&lt;/p&gt;
&lt;p&gt;-&amp;amp;gt;interim_entry of ksmbd_work could be deleted after oplock is freed.
We don&amp;amp;apos;t need to manage it with linked list. The interim request could be
immediately sent whenever a oplock break wait is needed.(CVE-2025-21967)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ksmbd: fix use-after-free in kerberos authentication&lt;/p&gt;
&lt;p&gt;Setting sess-&amp;amp;gt;user = NULL was introduced to fix the dangling pointer
created by ksmbd_free_user. However, it is possible another thread could
be operating on the session and make us…&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:&lt;/p&gt;
&lt;p&gt;rapidio: fix an API misues when rio_add_net() fails&lt;/p&gt;
&lt;p&gt;rio_add_net() calls device_register() and fails when device_register()
fails.  Thus, put_device() should be used rather than kfree().  Add
&amp;amp;quot;mport-&amp;amp;gt;net = NULL;&amp;amp;quot; to avoid a use after free issue.(CVE-2025-21934)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;cifs: Fix integer overflow while processing closetimeo mount option&lt;/p&gt;
&lt;p&gt;User-provided mount parameter closetimeo of type u32 is intended to have
an upper limit, but before it is validated, the value is converted from
seconds to jiffies which can lead to an integer overflow.&lt;/p&gt;
&lt;p&gt;Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21962)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ksmbd: fix use-after-free in ksmbd_free_work_struct&lt;/p&gt;
&lt;p&gt;-&amp;amp;gt;interim_entry of ksmbd_work could be deleted after oplock is freed.
We don&amp;amp;apos;t need to manage it with linked list. The interim request could be
immediately sent whenever a oplock break wait is needed.(CVE-2025-21967)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ksmbd: fix use-after-free in kerberos authentication&lt;/p&gt;
&lt;p&gt;Setting sess-&amp;amp;gt;user = NULL was introduced to fix the dangling pointer
created by ksmbd_free_user. However, it is possible another thread could
be operating on the session and make us…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-2268</guid>
    </item>
    <item>
      <title>openSUSE-SU-2025:20081-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-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/opensuse-su-2025:20081-1</guid>
    </item>
    <item>
      <title>SSA-032379 — SSA-032379: Multiple Vulnerabilities in SIMATIC CN 4100 Before V5.0</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-032379</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amd/display: Check link_res-&amp;gt;hpo_dp_link_enc before using it&#13;
&#13;
[WHAT &amp;amp; HOW]&#13;
Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res&#13;
without initializing hpo_dp_link_enc and it is necessary to check for&#13;
null before dereferencing.&#13;
&#13;
This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs: relax assertions on failure to encode file handles&lt;/p&gt;
&lt;p&gt;Encoding file handles is usually performed by a filesystem &amp;gt;encode_fh()
method that may fail for various reasons.&lt;/p&gt;
&lt;p&gt;The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.&lt;/p&gt;
&lt;p&gt;There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when -&amp;gt;encode_fh() fails.
Relax those assertions because they are wrong.&lt;/p&gt;
&lt;p&gt;The second linked bug report states commit 16aac5ad1fa9 (&amp;#34;ovl: support
encoding non-decodable file handles&amp;#34;) in v6.6 as the regressing commit,
but this is not accurate.&lt;/p&gt;
&lt;p&gt;The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.&lt;/p&gt;
&lt;p&gt;Triggering this assertion was always possible with other filesystems and
other reasons of -&amp;gt;encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlay…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amd/display: Check link_res-&amp;gt;hpo_dp_link_enc before using it&#13;
&#13;
[WHAT &amp;amp; HOW]&#13;
Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res&#13;
without initializing hpo_dp_link_enc and it is necessary to check for&#13;
null before dereferencing.&#13;
&#13;
This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs: relax assertions on failure to encode file handles&lt;/p&gt;
&lt;p&gt;Encoding file handles is usually performed by a filesystem &amp;gt;encode_fh()
method that may fail for various reasons.&lt;/p&gt;
&lt;p&gt;The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.&lt;/p&gt;
&lt;p&gt;There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when -&amp;gt;encode_fh() fails.
Relax those assertions because they are wrong.&lt;/p&gt;
&lt;p&gt;The second linked bug report states commit 16aac5ad1fa9 (&amp;#34;ovl: support
encoding non-decodable file handles&amp;#34;) in v6.6 as the regressing commit,
but this is not accurate.&lt;/p&gt;
&lt;p&gt;The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.&lt;/p&gt;
&lt;p&gt;Triggering this assertion was always possible with other filesystems and
other reasons of -&amp;gt;encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlay…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-032379</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:03600-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:03600-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:03600-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-38687</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38687</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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, Ubuntu:16.04:LTS: linux-hwe-edge and 214 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: comedi: fix race between polling and detaching syzbot reports a use-after-free in comedi in the below link, which is due to comedi gladly removing the allocated async area even though poll requests are still active on the wait_queue_head inside of it. This can cause a use-after-free when the poll entries are later triggered or removed, as the memory for the wait_queue_head has been freed.  We need to check there are no tasks queued on any of the subdevices&amp;#39; wait queues before allowing the device to be detached by the `COMEDI_DEVCONFIG` ioctl. Tasks will read-lock `dev-&amp;gt;attach_lock` before adding themselves to the subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl handler by write-locking `dev-&amp;gt;attach_lock` before checking that all of the subdevices are safe to be deleted.  This includes testing for any sleepers on the subdevices&amp;#39; wait queues.  It remains locked until the device has been detached.  This requires the `comedi_device_detach()` function to be refactored slightly, moving the bulk of it into new function `comedi_device_detach_locked()`. Note that the refactor of `comedi_device_detach()` results in `comedi_device_cancel_all()` now being called while `dev-&amp;gt;attach_lock` is write-locked, which wasn&amp;#39;t the case previously, but that does not matter. Thanks to Jens Axboe for diagnosing the problem and co-developing this patch.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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, Ubuntu:16.04:LTS: linux-hwe-edge and 214 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: comedi: fix race between polling and detaching syzbot reports a use-after-free in comedi in the below link, which is due to comedi gladly removing the allocated async area even though poll requests are still active on the wait_queue_head inside of it. This can cause a use-after-free when the poll entries are later triggered or removed, as the memory for the wait_queue_head has been freed.  We need to check there are no tasks queued on any of the subdevices&amp;#39; wait queues before allowing the device to be detached by the `COMEDI_DEVCONFIG` ioctl. Tasks will read-lock `dev-&amp;gt;attach_lock` before adding themselves to the subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl handler by write-locking `dev-&amp;gt;attach_lock` before checking that all of the subdevices are safe to be deleted.  This includes testing for any sleepers on the subdevices&amp;#39; wait queues.  It remains locked until the device has been detached.  This requires the `comedi_device_detach()` function to be refactored slightly, moving the bulk of it into new function `comedi_device_detach_locked()`. Note that the refactor of `comedi_device_detach()` results in `comedi_device_cancel_all()` now being called while `dev-&amp;gt;attach_lock` is write-locked, which wasn&amp;#39;t the case previously, but that does not matter. Thanks to Jens Axboe for diagnosing the problem and co-developing this patch.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38687</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-1976 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1976</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder andere nicht spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder andere nicht spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1976</guid>
    </item>
  </channel>
</rss>
