<?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 15:27:13 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-11770</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-11770</link>
      <description>bdu:2026-11770</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-11770</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-45891</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-45891</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-2026-45891</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0831 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0831</link>
      <description>certfr-2026-avi-0831</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0831</guid>
    </item>
    <item>
      <title>EUVD-2026-321813</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-321813</link>
      <description>EUVD-2026-321813</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-321813</guid>
    </item>
    <item>
      <title>fkie_cve-2026-45891</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-45891</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: hns3: fix double free issue for tx spare buffer&lt;/p&gt;
&lt;p&gt;In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure
is created for rollback. However, the tx_spare pointer in the original
ring handle is incorrectly left pointing to the old backup memory.&lt;/p&gt;
&lt;p&gt;Later, if memory allocation fails in hns3_init_all_ring() during the setup,
the error path attempts to free all newly allocated rings. Since tx_spare
contains a stale (non-NULL) pointer from the backup, it is mistaken for
a newly allocated buffer and is erroneously freed, leading to a double-free
of the backup memory.&lt;/p&gt;
&lt;p&gt;The root cause is that the tx_spare field was not cleared after its value
was saved in tmp_rings, leaving a dangling pointer.&lt;/p&gt;
&lt;p&gt;Fix this by setting tx_spare to NULL in the original ring structure
when the creation of the new `tx_spare` fails. This ensures the
error cleanup path only frees genuinely newly allocated buffers.&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;net: hns3: fix double free issue for tx spare buffer&lt;/p&gt;
&lt;p&gt;In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure
is created for rollback. However, the tx_spare pointer in the original
ring handle is incorrectly left pointing to the old backup memory.&lt;/p&gt;
&lt;p&gt;Later, if memory allocation fails in hns3_init_all_ring() during the setup,
the error path attempts to free all newly allocated rings. Since tx_spare
contains a stale (non-NULL) pointer from the backup, it is mistaken for
a newly allocated buffer and is erroneously freed, leading to a double-free
of the backup memory.&lt;/p&gt;
&lt;p&gt;The root cause is that the tx_spare field was not cleared after its value
was saved in tmp_rings, leaving a dangling pointer.&lt;/p&gt;
&lt;p&gt;Fix this by setting tx_spare to NULL in the original ring structure
when the creation of the new `tx_spare` fails. This ensures the
error cleanup path only frees genuinely newly allocated buffers.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-45891</guid>
    </item>
    <item>
      <title>GHSA-h6g2-742c-p38f</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-h6g2-742c-p38f</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: hns3: fix double free issue for tx spare buffer&lt;/p&gt;
&lt;p&gt;In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure
is created for rollback. However, the tx_spare pointer in the original
ring handle is incorrectly left pointing to the old backup memory.&lt;/p&gt;
&lt;p&gt;Later, if memory allocation fails in hns3_init_all_ring() during the setup,
the error path attempts to free all newly allocated rings. Since tx_spare
contains a stale (non-NULL) pointer from the backup, it is mistaken for
a newly allocated buffer and is erroneously freed, leading to a double-free
of the backup memory.&lt;/p&gt;
&lt;p&gt;The root cause is that the tx_spare field was not cleared after its value
was saved in tmp_rings, leaving a dangling pointer.&lt;/p&gt;
&lt;p&gt;Fix this by setting tx_spare to NULL in the original ring structure
when the creation of the new `tx_spare` fails. This ensures the
error cleanup path only frees genuinely newly allocated buffers.&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;net: hns3: fix double free issue for tx spare buffer&lt;/p&gt;
&lt;p&gt;In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure
is created for rollback. However, the tx_spare pointer in the original
ring handle is incorrectly left pointing to the old backup memory.&lt;/p&gt;
&lt;p&gt;Later, if memory allocation fails in hns3_init_all_ring() during the setup,
the error path attempts to free all newly allocated rings. Since tx_spare
contains a stale (non-NULL) pointer from the backup, it is mistaken for
a newly allocated buffer and is erroneously freed, leading to a double-free
of the backup memory.&lt;/p&gt;
&lt;p&gt;The root cause is that the tx_spare field was not cleared after its value
was saved in tmp_rings, leaving a dangling pointer.&lt;/p&gt;
&lt;p&gt;Fix this by setting tx_spare to NULL in the original ring structure
when the creation of the new `tx_spare` fails. This ensures the
error cleanup path only frees genuinely newly allocated buffers.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-h6g2-742c-p38f</guid>
    </item>
    <item>
      <title>OESA-2026-2675 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-2675</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;drm/i915/gt: Fix timeline left held on VMA alloc error&lt;/p&gt;
&lt;p&gt;The following error has been reported sporadically by CI when a test
unbinds the i915 driver on a ring submission platform:&lt;/p&gt;
&lt;p&gt;&amp;amp;lt;4&amp;amp;gt; [239.330153] ------------[ cut here ]------------
&amp;amp;lt;4&amp;amp;gt; [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv-&amp;amp;gt;mm.shrink_count)
&amp;amp;lt;4&amp;amp;gt; [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]
...
&amp;amp;lt;4&amp;amp;gt; [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]
...
&amp;amp;lt;4&amp;amp;gt; [239.330942] Call Trace:
&amp;amp;lt;4&amp;amp;gt; [239.330944]  &amp;amp;lt;TASK&amp;amp;gt;
&amp;amp;lt;4&amp;amp;gt; [239.330949]  i915_driver_late_release+0x2b/0xa0 [i915]
&amp;amp;lt;4&amp;amp;gt; [239.331202]  i915_driver_release+0x86/0xa0 [i915]
&amp;amp;lt;4&amp;amp;gt; [239.331482]  devm_drm_dev_init_release+0x61/0x90
&amp;amp;lt;4&amp;amp;gt; [239.331494]  devm_action_release+0x15/0x30
&amp;amp;lt;4&amp;amp;gt; [239.331504]  release_nodes+0x3d/0x120
&amp;amp;lt;4&amp;amp;gt; [239.331517]  devres_release_all+0x96/0xd0
&amp;amp;lt;4&amp;amp;gt; [239.331533]  device_unbind_cleanup+0x12/0x80
&amp;amp;lt;4&amp;amp;gt; [239.331543]  device_release_driver_internal+0x23a/0x280
&amp;amp;lt;4&amp;amp;gt; [239.331550]  ? bus_find_device+0xa5/0xe0
&amp;amp;lt;4&amp;amp;gt; [239.331563]  device_driver_detach+0x14/0x20
...
&amp;amp;lt;4&amp;amp;gt; [357.719679] ---[ end trace 0000000000000000 ]---&lt;/p&gt;
&lt;p&gt;If the test also unloads the i915 module then that&amp;amp;apos;s followed with:&lt;/p&gt;
&lt;p&gt;&amp;amp;lt;3&amp;amp;gt; [357.787478] ===…&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;drm/i915/gt: Fix timeline left held on VMA alloc error&lt;/p&gt;
&lt;p&gt;The following error has been reported sporadically by CI when a test
unbinds the i915 driver on a ring submission platform:&lt;/p&gt;
&lt;p&gt;&amp;amp;lt;4&amp;amp;gt; [239.330153] ------------[ cut here ]------------
&amp;amp;lt;4&amp;amp;gt; [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv-&amp;amp;gt;mm.shrink_count)
&amp;amp;lt;4&amp;amp;gt; [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]
...
&amp;amp;lt;4&amp;amp;gt; [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]
...
&amp;amp;lt;4&amp;amp;gt; [239.330942] Call Trace:
&amp;amp;lt;4&amp;amp;gt; [239.330944]  &amp;amp;lt;TASK&amp;amp;gt;
&amp;amp;lt;4&amp;amp;gt; [239.330949]  i915_driver_late_release+0x2b/0xa0 [i915]
&amp;amp;lt;4&amp;amp;gt; [239.331202]  i915_driver_release+0x86/0xa0 [i915]
&amp;amp;lt;4&amp;amp;gt; [239.331482]  devm_drm_dev_init_release+0x61/0x90
&amp;amp;lt;4&amp;amp;gt; [239.331494]  devm_action_release+0x15/0x30
&amp;amp;lt;4&amp;amp;gt; [239.331504]  release_nodes+0x3d/0x120
&amp;amp;lt;4&amp;amp;gt; [239.331517]  devres_release_all+0x96/0xd0
&amp;amp;lt;4&amp;amp;gt; [239.331533]  device_unbind_cleanup+0x12/0x80
&amp;amp;lt;4&amp;amp;gt; [239.331543]  device_release_driver_internal+0x23a/0x280
&amp;amp;lt;4&amp;amp;gt; [239.331550]  ? bus_find_device+0xa5/0xe0
&amp;amp;lt;4&amp;amp;gt; [239.331563]  device_driver_detach+0x14/0x20
...
&amp;amp;lt;4&amp;amp;gt; [357.719679] ---[ end trace 0000000000000000 ]---&lt;/p&gt;
&lt;p&gt;If the test also unloads the i915 module then that&amp;amp;apos;s followed with:&lt;/p&gt;
&lt;p&gt;&amp;amp;lt;3&amp;amp;gt; [357.787478] ===…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-2675</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21388-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21388-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-2026:21388-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:22521-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:22521-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-2026:22521-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-45891</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45891</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 179 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix double free issue for tx spare buffer In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 179 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix double free issue for tx spare buffer In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45891</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1700 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</guid>
    </item>
  </channel>
</rss>
