<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-05T13:26:18.899002+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bdu:2025-03759</id>
    <title>bdu:2025-03759</title>
    <updated>2026-10-05T13:26:19.591011+00:00</updated>
    <content>bdu:2025-03759</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2025-03759"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2024-46681</id>
    <title>BELL-CVE-2024-46681</title>
    <updated>2026-10-05T13:26:19.591077+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2024-46681"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2024-avi-1080</id>
    <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>
    <updated>2026-10-05T13:26:19.591111+00:00</updated>
    <content>certfr-2024-avi-1080</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2024-avi-1080"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-313222</id>
    <title>EUVD-2026-313222</title>
    <updated>2026-10-05T13:26:19.591129+00:00</updated>
    <content>EUVD-2026-313222</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-313222"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2024-46681</id>
    <title>fkie_cve-2024-46681</title>
    <updated>2026-10-05T13:26:19.591141+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>pktgen: use cpus_read_lock() in pg_net_init()</p>
<p>I have seen the WARN_ON(smp_processor_id() != cpu) firing
in pktgen_thread_worker() during tests.</p>
<p>We must use cpus_read_lock()/cpus_read_unlock()
around the for_each_online_cpu(cpu) loop.</p>
<p>While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2024-46681"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-5mq7-93mw-h965</id>
    <title>GHSA-5mq7-93mw-h965</title>
    <updated>2026-10-05T13:26:19.591170+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>pktgen: use cpus_read_lock() in pg_net_init()</p>
<p>I have seen the WARN_ON(smp_processor_id() != cpu) firing
in pktgen_thread_worker() during tests.</p>
<p>We must use cpus_read_lock()/cpus_read_unlock()
around the for_each_online_cpu(cpu) loop.</p>
<p>While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-5mq7-93mw-h965"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2024-46681</id>
    <title>msrc_CVE-2024-46681 — pktgen: use cpus_read_lock() in pg_net_init()</title>
    <updated>2026-10-05T13:26:19.591189+00:00</updated>
    <content>msrc_CVE-2024-46681</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2024-46681"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2024-2216</id>
    <title>OESA-2024-2216 — kernel security update</title>
    <updated>2026-10-05T13:26:19.591205+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> openEuler:22.03-LTS-SP3: kernel</p>
<p>The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Stop parsing channels bits when all channels are found.

If a usb audio device sets more bits than the amount of channels
it could write outside of the map array.(CVE-2024-27436)

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete

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:

    DWC3 Gadget                               FFS Application
dwc3_gadget_soft_disconnect()              ...
  --&amp;gt; dwc3_stop_active_transfers()
    --&amp;gt; dwc3_gadget_giveback(-ESHUTDOWN)
      --&amp;gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()
        --&amp;gt; usb_ep_free_request()            --&amp;gt; usb_ep_dequeue()

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;gt;req) the FFS
application is also referencing it for the usb_ep_dequeue() call.  This can…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2024-2216"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2024:4314-1</id>
    <title>SUSE-SU-2024:4314-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-05T13:26:19.591445+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2024:4314-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-46681</id>
    <title>UBUNTU-CVE-2024-46681</title>
    <updated>2026-10-05T13:26:19.591613+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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</p>
<p>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.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-46681"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-2133</id>
    <title>WID-SEC-W-2024-2133 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-05T13:26:19.591832+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder einen unspezifischen Angriff durchzuführen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2024-2133"/>
  </entry>
</feed>
