<?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>Sat, 03 Oct 2026 19:58:38 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-10417</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-10417</link>
      <description>bdu:2024-10417</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-10417</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-52754</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-52754</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-2023-52754</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0496 — 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-2024-avi-0496</link>
      <description>certfr-2024-avi-0496</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0496</guid>
    </item>
    <item>
      <title>EUVD-2026-311662</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-311662</link>
      <description>EUVD-2026-311662</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-311662</guid>
    </item>
    <item>
      <title>fkie_cve-2023-52754</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-52754</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: imon: fix access to invalid resource for the second interface&lt;/p&gt;
&lt;p&gt;imon driver probes two USB interfaces, and at the probe of the second
interface, the driver assumes blindly that the first interface got
bound with the same imon driver.  It&amp;#39;s usually true, but it&amp;#39;s still
possible that the first interface is bound with another driver via a
malformed descriptor.  Then it may lead to a memory corruption, as
spotted by syzkaller; imon driver accesses the data from drvdata as
struct imon_context object although it&amp;#39;s a completely different one
that was assigned by another driver.&lt;/p&gt;
&lt;p&gt;This patch adds a sanity check -- whether the first interface is
really bound with the imon driver or not -- for avoiding the problem
above at the probe time.&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;media: imon: fix access to invalid resource for the second interface&lt;/p&gt;
&lt;p&gt;imon driver probes two USB interfaces, and at the probe of the second
interface, the driver assumes blindly that the first interface got
bound with the same imon driver.  It&amp;#39;s usually true, but it&amp;#39;s still
possible that the first interface is bound with another driver via a
malformed descriptor.  Then it may lead to a memory corruption, as
spotted by syzkaller; imon driver accesses the data from drvdata as
struct imon_context object although it&amp;#39;s a completely different one
that was assigned by another driver.&lt;/p&gt;
&lt;p&gt;This patch adds a sanity check -- whether the first interface is
really bound with the imon driver or not -- for avoiding the problem
above at the probe time.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-52754</guid>
    </item>
    <item>
      <title>GHSA-2qm9-92xg-cr8h</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-2qm9-92xg-cr8h</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: imon: fix access to invalid resource for the second interface&lt;/p&gt;
&lt;p&gt;imon driver probes two USB interfaces, and at the probe of the second
interface, the driver assumes blindly that the first interface got
bound with the same imon driver.  It&amp;#39;s usually true, but it&amp;#39;s still
possible that the first interface is bound with another driver via a
malformed descriptor.  Then it may lead to a memory corruption, as
spotted by syzkaller; imon driver accesses the data from drvdata as
struct imon_context object although it&amp;#39;s a completely different one
that was assigned by another driver.&lt;/p&gt;
&lt;p&gt;This patch adds a sanity check -- whether the first interface is
really bound with the imon driver or not -- for avoiding the problem
above at the probe time.&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;media: imon: fix access to invalid resource for the second interface&lt;/p&gt;
&lt;p&gt;imon driver probes two USB interfaces, and at the probe of the second
interface, the driver assumes blindly that the first interface got
bound with the same imon driver.  It&amp;#39;s usually true, but it&amp;#39;s still
possible that the first interface is bound with another driver via a
malformed descriptor.  Then it may lead to a memory corruption, as
spotted by syzkaller; imon driver accesses the data from drvdata as
struct imon_context object although it&amp;#39;s a completely different one
that was assigned by another driver.&lt;/p&gt;
&lt;p&gt;This patch adds a sanity check -- whether the first interface is
really bound with the imon driver or not -- for avoiding the problem
above at the probe time.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-2qm9-92xg-cr8h</guid>
    </item>
    <item>
      <title>OESA-2024-1705 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1705</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: 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;
net: cdc_eem: fix tx fixup skb leak&#13;
&#13;
when usbnet transmit a skb, eem fixup it in eem_tx_fixup(),
if skb_copy_expand() failed, it return NULL,
usbnet_start_xmit() will have no chance to free original skb.&#13;
&#13;
fix it by free orginal skb in eem_tx_fixup() first,
then check skb clone status, if failed, return NULL to usbnet.(CVE-2021-47236)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
gfs2: Fix use-after-free in gfs2_glock_shrink_scan&#13;
&#13;
The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to
remove the glock from the lru list in __gfs2_glock_put().&#13;
&#13;
On the shrink scan path, the same flag is cleared under lru_lock but because
of cond_resched_lock(&amp;amp;amp;lru_lock) in gfs2_dispose_glock_lru(), progress on the
put side can be made without deleting the glock from the lru list.&#13;
&#13;
Keep GLF_LRU across the race window opened by cond_resched_lock(&amp;amp;amp;lru_lock) to
ensure correct behavior on both sides - clear GLF_LRU after list_del under
lru_lock.(CVE-2021-47254)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netrom: Decrease sock refcount when sock timers expire&#13;
&#13;
Commit 63346650c1a9 (&amp;amp;quot;netrom: switch to sock timer API&amp;amp;quot;) switched to use
sock timer API. It replaces mod_timer() by sk_reset_timer(), and
del_timer() by sk_stop_timer().&#13;
&#13;
Function sk_reset_t…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: 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;
net: cdc_eem: fix tx fixup skb leak&#13;
&#13;
when usbnet transmit a skb, eem fixup it in eem_tx_fixup(),
if skb_copy_expand() failed, it return NULL,
usbnet_start_xmit() will have no chance to free original skb.&#13;
&#13;
fix it by free orginal skb in eem_tx_fixup() first,
then check skb clone status, if failed, return NULL to usbnet.(CVE-2021-47236)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
gfs2: Fix use-after-free in gfs2_glock_shrink_scan&#13;
&#13;
The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to
remove the glock from the lru list in __gfs2_glock_put().&#13;
&#13;
On the shrink scan path, the same flag is cleared under lru_lock but because
of cond_resched_lock(&amp;amp;amp;lru_lock) in gfs2_dispose_glock_lru(), progress on the
put side can be made without deleting the glock from the lru list.&#13;
&#13;
Keep GLF_LRU across the race window opened by cond_resched_lock(&amp;amp;amp;lru_lock) to
ensure correct behavior on both sides - clear GLF_LRU after list_del under
lru_lock.(CVE-2021-47254)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netrom: Decrease sock refcount when sock timers expire&#13;
&#13;
Commit 63346650c1a9 (&amp;amp;quot;netrom: switch to sock timer API&amp;amp;quot;) switched to use
sock timer API. It replaces mod_timer() by sk_reset_timer(), and
del_timer() by sk_stop_timer().&#13;
&#13;
Function sk_reset_t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1705</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2008-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2008-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:2008-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-52754</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52754</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 159 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: media: imon: fix access to invalid resource for the second interface imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver.  It&amp;#39;s usually true, but it&amp;#39;s still possible that the first interface is bound with another driver via a malformed descriptor.  Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it&amp;#39;s a completely different one that was assigned by another driver. This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time.&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 159 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: media: imon: fix access to invalid resource for the second interface imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver.  It&amp;#39;s usually true, but it&amp;#39;s still possible that the first interface is bound with another driver via a malformed descriptor.  Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it&amp;#39;s a completely different one that was assigned by another driver. This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52754</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1197 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service und unspezifische Angriffe</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1197</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder unspezifische Angriffe 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-Zustand zu erzeugen oder unspezifische Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1197</guid>
    </item>
  </channel>
</rss>
