<?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 16:00:22 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-74575</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-74575</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-74575</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1090 — 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-2026-avi-1090</link>
      <description>certfr-2026-avi-1090</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1090</guid>
    </item>
    <item>
      <title>EUVD-2026-357922</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-357922</link>
      <description>EUVD-2026-357922</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-357922</guid>
    </item>
    <item>
      <title>fkie_cve-2026-74575</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-74575</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;thunderbolt: Prevent XDomain delayed work use-after-free on disconnect&lt;/p&gt;
&lt;p&gt;tb_xdp_handle_request() runs on system_wq and queues
xd-&amp;gt;state_work via queue_delayed_work() in three request handlers:
PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake),
and LINK_STATE_CHANGE_REQUEST.  Similarly, update_xdomain() queues
xd-&amp;gt;properties_changed_work when local properties change.&lt;/p&gt;
&lt;p&gt;Concurrently, tb_xdomain_remove() calls stop_handshake() which does
cancel_delayed_work_sync() on both delayed works.  Later,
tb_xdomain_unregister() calls device_unregister() which eventually
frees the xdomain.  Since commit 559c1e1e0134 (&amp;#34;thunderbolt: Run
tb_xdp_handle_request() in system workqueue&amp;#34;) moved the request
handler off tb-&amp;gt;wq, the handler and the remove path are no longer
serialized.  If queue_delayed_work() executes after
cancel_delayed_work_sync() but before the xdomain is freed, the
delayed work fires on a freed object.&lt;/p&gt;
&lt;p&gt;Add xd-&amp;gt;removing that tb_xdomain_remove() sets under xd-&amp;gt;lock
before calling stop_handshake().  Each external queue site holds
the same lock and checks removing before calling
queue_delayed_work().  This provides the mutual exclusion needed:
either the queue site acquires the lock first and queues work that
the subsequent cancel will see, or the remove path acquires the
lock first and the queue site observes removing == true and skips
the queue.&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;thunderbolt: Prevent XDomain delayed work use-after-free on disconnect&lt;/p&gt;
&lt;p&gt;tb_xdp_handle_request() runs on system_wq and queues
xd-&amp;gt;state_work via queue_delayed_work() in three request handlers:
PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake),
and LINK_STATE_CHANGE_REQUEST.  Similarly, update_xdomain() queues
xd-&amp;gt;properties_changed_work when local properties change.&lt;/p&gt;
&lt;p&gt;Concurrently, tb_xdomain_remove() calls stop_handshake() which does
cancel_delayed_work_sync() on both delayed works.  Later,
tb_xdomain_unregister() calls device_unregister() which eventually
frees the xdomain.  Since commit 559c1e1e0134 (&amp;#34;thunderbolt: Run
tb_xdp_handle_request() in system workqueue&amp;#34;) moved the request
handler off tb-&amp;gt;wq, the handler and the remove path are no longer
serialized.  If queue_delayed_work() executes after
cancel_delayed_work_sync() but before the xdomain is freed, the
delayed work fires on a freed object.&lt;/p&gt;
&lt;p&gt;Add xd-&amp;gt;removing that tb_xdomain_remove() sets under xd-&amp;gt;lock
before calling stop_handshake().  Each external queue site holds
the same lock and checks removing before calling
queue_delayed_work().  This provides the mutual exclusion needed:
either the queue site acquires the lock first and queues work that
the subsequent cancel will see, or the remove path acquires the
lock first and the queue site observes removing == true and skips
the queue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-74575</guid>
    </item>
    <item>
      <title>GHSA-87c7-v43r-f3f4</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-87c7-v43r-f3f4</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;thunderbolt: Prevent XDomain delayed work use-after-free on disconnect&lt;/p&gt;
&lt;p&gt;tb_xdp_handle_request() runs on system_wq and queues
xd-&amp;gt;state_work via queue_delayed_work() in three request handlers:
PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake),
and LINK_STATE_CHANGE_REQUEST.  Similarly, update_xdomain() queues
xd-&amp;gt;properties_changed_work when local properties change.&lt;/p&gt;
&lt;p&gt;Concurrently, tb_xdomain_remove() calls stop_handshake() which does
cancel_delayed_work_sync() on both delayed works.  Later,
tb_xdomain_unregister() calls device_unregister() which eventually
frees the xdomain.  Since commit 559c1e1e0134 (&amp;#34;thunderbolt: Run
tb_xdp_handle_request() in system workqueue&amp;#34;) moved the request
handler off tb-&amp;gt;wq, the handler and the remove path are no longer
serialized.  If queue_delayed_work() executes after
cancel_delayed_work_sync() but before the xdomain is freed, the
delayed work fires on a freed object.&lt;/p&gt;
&lt;p&gt;Add xd-&amp;gt;removing that tb_xdomain_remove() sets under xd-&amp;gt;lock
before calling stop_handshake().  Each external queue site holds
the same lock and checks removing before calling
queue_delayed_work().  This provides the mutual exclusion needed:
either the queue site acquires the lock first and queues work that
the subsequent cancel will see, or the remove path acquires the
lock first and the queue site observes removing == true and skips
the queue.&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;thunderbolt: Prevent XDomain delayed work use-after-free on disconnect&lt;/p&gt;
&lt;p&gt;tb_xdp_handle_request() runs on system_wq and queues
xd-&amp;gt;state_work via queue_delayed_work() in three request handlers:
PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake),
and LINK_STATE_CHANGE_REQUEST.  Similarly, update_xdomain() queues
xd-&amp;gt;properties_changed_work when local properties change.&lt;/p&gt;
&lt;p&gt;Concurrently, tb_xdomain_remove() calls stop_handshake() which does
cancel_delayed_work_sync() on both delayed works.  Later,
tb_xdomain_unregister() calls device_unregister() which eventually
frees the xdomain.  Since commit 559c1e1e0134 (&amp;#34;thunderbolt: Run
tb_xdp_handle_request() in system workqueue&amp;#34;) moved the request
handler off tb-&amp;gt;wq, the handler and the remove path are no longer
serialized.  If queue_delayed_work() executes after
cancel_delayed_work_sync() but before the xdomain is freed, the
delayed work fires on a freed object.&lt;/p&gt;
&lt;p&gt;Add xd-&amp;gt;removing that tb_xdomain_remove() sets under xd-&amp;gt;lock
before calling stop_handshake().  Each external queue site holds
the same lock and checks removing before calling
queue_delayed_work().  This provides the mutual exclusion needed:
either the queue site acquires the lock first and queues work that
the subsequent cancel will see, or the remove path acquires the
lock first and the queue site observes removing == true and skips
the queue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-87c7-v43r-f3f4</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-74575 — thunderbolt: Prevent XDomain delayed work use-after-free on disconnect</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-74575</link>
      <description>msrc_CVE-2026-74575</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-74575</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-74575</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74575</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Prevent XDomain delayed work use-after-free on disconnect tb_xdp_handle_request() runs on system_wq and queues xd-&amp;gt;state_work via queue_delayed_work() in three request handlers: PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake), and LINK_STATE_CHANGE_REQUEST.  Similarly, update_xdomain() queues xd-&amp;gt;properties_changed_work when local properties change. Concurrently, tb_xdomain_remove() calls stop_handshake() which does cancel_delayed_work_sync() on both delayed works.  Later, tb_xdomain_unregister() calls device_unregister() which eventually frees the xdomain.  Since commit 559c1e1e0134 (&amp;#34;thunderbolt: Run tb_xdp_handle_request() in system workqueue&amp;#34;) moved the request handler off tb-&amp;gt;wq, the handler and the remove path are no longer serialized.  If queue_delayed_work() executes after cancel_delayed_work_sync() but before the xdomain is freed, the delayed work fires on a freed object. Add xd-&amp;gt;removing that tb_xdomain_remove() sets under xd-&amp;gt;lock before calling stop_handshake().  Each external queue site holds the same lock and checks removing before calling queue_delayed_work().  This provides the mutual exclusion needed: either the queue site acquires the lock first and queues work that the subsequent cancel will see, or the remove path acquires the lock first and the queue site observes removing == true and skips the queue.&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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Prevent XDomain delayed work use-after-free on disconnect tb_xdp_handle_request() runs on system_wq and queues xd-&amp;gt;state_work via queue_delayed_work() in three request handlers: PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake), and LINK_STATE_CHANGE_REQUEST.  Similarly, update_xdomain() queues xd-&amp;gt;properties_changed_work when local properties change. Concurrently, tb_xdomain_remove() calls stop_handshake() which does cancel_delayed_work_sync() on both delayed works.  Later, tb_xdomain_unregister() calls device_unregister() which eventually frees the xdomain.  Since commit 559c1e1e0134 (&amp;#34;thunderbolt: Run tb_xdp_handle_request() in system workqueue&amp;#34;) moved the request handler off tb-&amp;gt;wq, the handler and the remove path are no longer serialized.  If queue_delayed_work() executes after cancel_delayed_work_sync() but before the xdomain is freed, the delayed work fires on a freed object. Add xd-&amp;gt;removing that tb_xdomain_remove() sets under xd-&amp;gt;lock before calling stop_handshake().  Each external queue site holds the same lock and checks removing before calling queue_delayed_work().  This provides the mutual exclusion needed: either the queue site acquires the lock first and queues work that the subsequent cancel will see, or the remove path acquires the lock first and the queue site observes removing == true and skips the queue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74575</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2852 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852</guid>
    </item>
  </channel>
</rss>
