<?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>Mon, 05 Oct 2026 16:52:57 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-03759</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-03759</link>
      <description>bdu:2025-03759</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-03759</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-46681</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-46681</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-46681</guid>
    </item>
    <item>
      <title>certfr-2024-avi-1080 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Elles permettent à un attaquant de provoq…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-1080</link>
      <description>certfr-2024-avi-1080</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-1080</guid>
    </item>
    <item>
      <title>EUVD-2026-313222</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-313222</link>
      <description>EUVD-2026-313222</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-313222</guid>
    </item>
    <item>
      <title>fkie_cve-2024-46681</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-46681</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;pktgen: use cpus_read_lock() in pg_net_init()&lt;/p&gt;
&lt;p&gt;I have seen the WARN_ON(smp_processor_id() != cpu) firing
in pktgen_thread_worker() during tests.&lt;/p&gt;
&lt;p&gt;We must use cpus_read_lock()/cpus_read_unlock()
around the for_each_online_cpu(cpu) loop.&lt;/p&gt;
&lt;p&gt;While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.&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;pktgen: use cpus_read_lock() in pg_net_init()&lt;/p&gt;
&lt;p&gt;I have seen the WARN_ON(smp_processor_id() != cpu) firing
in pktgen_thread_worker() during tests.&lt;/p&gt;
&lt;p&gt;We must use cpus_read_lock()/cpus_read_unlock()
around the for_each_online_cpu(cpu) loop.&lt;/p&gt;
&lt;p&gt;While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-46681</guid>
    </item>
    <item>
      <title>GHSA-5mq7-93mw-h965</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-5mq7-93mw-h965</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;pktgen: use cpus_read_lock() in pg_net_init()&lt;/p&gt;
&lt;p&gt;I have seen the WARN_ON(smp_processor_id() != cpu) firing
in pktgen_thread_worker() during tests.&lt;/p&gt;
&lt;p&gt;We must use cpus_read_lock()/cpus_read_unlock()
around the for_each_online_cpu(cpu) loop.&lt;/p&gt;
&lt;p&gt;While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.&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;pktgen: use cpus_read_lock() in pg_net_init()&lt;/p&gt;
&lt;p&gt;I have seen the WARN_ON(smp_processor_id() != cpu) firing
in pktgen_thread_worker() during tests.&lt;/p&gt;
&lt;p&gt;We must use cpus_read_lock()/cpus_read_unlock()
around the for_each_online_cpu(cpu) loop.&lt;/p&gt;
&lt;p&gt;While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-5mq7-93mw-h965</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-46681 — pktgen: use cpus_read_lock() in pg_net_init()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-46681</link>
      <description>msrc_CVE-2024-46681</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-46681</guid>
    </item>
    <item>
      <title>OESA-2024-2216 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2216</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
ALSA: usb-audio: Stop parsing channels bits when all channels are found.&#13;
&#13;
If a usb audio device sets more bits than the amount of channels
it could write outside of the map array.(CVE-2024-27436)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete&#13;
&#13;
FFS based applications can utilize the aio_cancel() callback to dequeue
pending USB requests submitted to the UDC.  There is a scenario where the
FFS application issues an AIO cancel call, while the UDC is handling a
soft disconnect.  For a DWC3 based implementation, the callstack looks
like the following:&#13;
&#13;
    DWC3 Gadget                               FFS Application
dwc3_gadget_soft_disconnect()              ...
  --&amp;amp;gt; dwc3_stop_active_transfers()
    --&amp;amp;gt; dwc3_gadget_giveback(-ESHUTDOWN)
      --&amp;amp;gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()
        --&amp;amp;gt; usb_ep_free_request()            --&amp;amp;gt; usb_ep_dequeue()&#13;
&#13;
There is currently no locking implemented between the AIO completion
handler and AIO cancel, so the issue occurs if the completion routine is
running in parallel to an AIO cancel call coming from the FFS application.
As the completion call frees the USB request (io_data-&amp;amp;gt;req) the FFS
application is also referencing it for the usb_ep_dequeue() call.  This can…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
ALSA: usb-audio: Stop parsing channels bits when all channels are found.&#13;
&#13;
If a usb audio device sets more bits than the amount of channels
it could write outside of the map array.(CVE-2024-27436)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete&#13;
&#13;
FFS based applications can utilize the aio_cancel() callback to dequeue
pending USB requests submitted to the UDC.  There is a scenario where the
FFS application issues an AIO cancel call, while the UDC is handling a
soft disconnect.  For a DWC3 based implementation, the callstack looks
like the following:&#13;
&#13;
    DWC3 Gadget                               FFS Application
dwc3_gadget_soft_disconnect()              ...
  --&amp;amp;gt; dwc3_stop_active_transfers()
    --&amp;amp;gt; dwc3_gadget_giveback(-ESHUTDOWN)
      --&amp;amp;gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()
        --&amp;amp;gt; usb_ep_free_request()            --&amp;amp;gt; usb_ep_dequeue()&#13;
&#13;
There is currently no locking implemented between the AIO completion
handler and AIO cancel, so the issue occurs if the completion routine is
running in parallel to an AIO cancel call coming from the FFS application.
As the completion call frees the USB request (io_data-&amp;amp;gt;req) the FFS
application is also referencing it for the usb_ep_dequeue() call.  This can…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2216</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:4314-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:4314-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-2024:4314-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-46681</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-46681</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 188 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: pktgen: use cpus_read_lock() in pg_net_init() I have seen the WARN_ON(smp_processor_id() != cpu) firing in pktgen_thread_worker() during tests. We must use cpus_read_lock()/cpus_read_unlock() around the for_each_online_cpu(cpu) loop. While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.&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 188 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: pktgen: use cpus_read_lock() in pg_net_init() I have seen the WARN_ON(smp_processor_id() != cpu) firing in pktgen_thread_worker() during tests. We must use cpus_read_lock()/cpus_read_unlock() around the for_each_online_cpu(cpu) loop. While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-46681</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-2133 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-2133</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-2133</guid>
    </item>
  </channel>
</rss>
