https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 05:36:50 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-12425 bdu:2026-12425 https://cve.radiocsirt.org/vuln/bdu:2026-12425 https://cve.radiocsirt.org/vuln/bell-cve-2025-40002 <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-40002 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0969 certfr-2025-avi-0969 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0969 https://cve.radiocsirt.org/vuln/euvd-2026-314850 EUVD-2026-314850 https://cve.radiocsirt.org/vuln/euvd-2026-314850 https://cve.radiocsirt.org/vuln/fkie_cve-2025-40002 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>thunderbolt: Fix use-after-free in tb_dp_dprx_work</p> <p>The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(), which does not ensure that the delayed work item tunnel-&gt;dprx_work has fully completed if it was already running. This leads to use-after-free scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while tunnel-&gt;dprx_work remains active and attempts to dereference tb_tunnel in tb_dp_dprx_work().</p> <p>A typical race condition is illustrated below:</p> <p>CPU 0 | CPU 1 tb_dp_tunnel_active() | tb_deactivate_and_free_tunnel()| tb_dp_dprx_start() tb_tunnel_deactivate() | queue_delayed_work() tb_dp_activate() | tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker cancel_delayed_work() | tb_tunnel_put(tunnel); | | tunnel = container_of(...); //UAF | tunnel-&gt; //UAF</p> <p>Replacing cancel_delayed_work() with cancel_delayed_work_sync() is not feasible as it would introduce a deadlock: both tb_dp_dprx_work() and the cleanup path acquire tb-&gt;lock, and cancel_delayed_work_sync() would wait indefinitely for the work item that cannot proceed.</p> <p>Instead, implement proper reference counting: - If cancel_delayed_work() returns true (work is pending), we release the reference in the stop function. - If it returns false (work is executing o…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>thunderbolt: Fix use-after-free in tb_dp_dprx_work</p> <p>The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(), which does not ensure that the delayed work item tunnel-&gt;dprx_work has fully completed if it was already running. This leads to use-after-free scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while tunnel-&gt;dprx_work remains active and attempts to dereference tb_tunnel in tb_dp_dprx_work().</p> <p>A typical race condition is illustrated below:</p> <p>CPU 0 | CPU 1 tb_dp_tunnel_active() | tb_deactivate_and_free_tunnel()| tb_dp_dprx_start() tb_tunnel_deactivate() | queue_delayed_work() tb_dp_activate() | tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker cancel_delayed_work() | tb_tunnel_put(tunnel); | | tunnel = container_of(...); //UAF | tunnel-&gt; //UAF</p> <p>Replacing cancel_delayed_work() with cancel_delayed_work_sync() is not feasible as it would introduce a deadlock: both tb_dp_dprx_work() and the cleanup path acquire tb-&gt;lock, and cancel_delayed_work_sync() would wait indefinitely for the work item that cannot proceed.</p> <p>Instead, implement proper reference counting: - If cancel_delayed_work() returns true (work is pending), we release the reference in the stop function. - If it returns false (work is executing o…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-40002 https://cve.radiocsirt.org/vuln/ghsa-x82v-x9cm-j5mp <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>thunderbolt: Fix use-after-free in tb_dp_dprx_work</p> <p>The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(), which does not ensure that the delayed work item tunnel-&gt;dprx_work has fully completed if it was already running. This leads to use-after-free scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while tunnel-&gt;dprx_work remains active and attempts to dereference tb_tunnel in tb_dp_dprx_work().</p> <p>A typical race condition is illustrated below:</p> <p>CPU 0 | CPU 1 tb_dp_tunnel_active() | tb_deactivate_and_free_tunnel()| tb_dp_dprx_start() tb_tunnel_deactivate() | queue_delayed_work() tb_dp_activate() | tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker cancel_delayed_work() | tb_tunnel_put(tunnel); | | tunnel = container_of(...); //UAF | tunnel-&gt; //UAF</p> <p>Replacing cancel_delayed_work() with cancel_delayed_work_sync() is not feasible as it would introduce a deadlock: both tb_dp_dprx_work() and the cleanup path acquire tb-&gt;lock, and cancel_delayed_work_sync() would wait indefinitely for the work item that cannot proceed.</p> <p>Instead, implement proper reference counting: - If cancel_delayed_work() returns true (work is pending), we release the reference in the stop function. - If it returns false (work is executing o…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>thunderbolt: Fix use-after-free in tb_dp_dprx_work</p> <p>The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(), which does not ensure that the delayed work item tunnel-&gt;dprx_work has fully completed if it was already running. This leads to use-after-free scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while tunnel-&gt;dprx_work remains active and attempts to dereference tb_tunnel in tb_dp_dprx_work().</p> <p>A typical race condition is illustrated below:</p> <p>CPU 0 | CPU 1 tb_dp_tunnel_active() | tb_deactivate_and_free_tunnel()| tb_dp_dprx_start() tb_tunnel_deactivate() | queue_delayed_work() tb_dp_activate() | tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker cancel_delayed_work() | tb_tunnel_put(tunnel); | | tunnel = container_of(...); //UAF | tunnel-&gt; //UAF</p> <p>Replacing cancel_delayed_work() with cancel_delayed_work_sync() is not feasible as it would introduce a deadlock: both tb_dp_dprx_work() and the cleanup path acquire tb-&gt;lock, and cancel_delayed_work_sync() would wait indefinitely for the work item that cannot proceed.</p> <p>Instead, implement proper reference counting: - If cancel_delayed_work() returns true (work is pending), we release the reference in the stop function. - If it returns false (work is executing o…</p> https://cve.radiocsirt.org/vuln/ghsa-x82v-x9cm-j5mp https://cve.radiocsirt.org/vuln/opensuse-su-2025:15671-1 <p>kernel-devel-6.17.5-1.1 on GA media</p> <p>kernel-devel-6.17.5-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2025:15671-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40002 <p><strong>Affected:</strong> 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 102 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix use-after-free in tb_dp_dprx_work The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(), which does not ensure that the delayed work item tunnel-&gt;dprx_work has fully completed if it was already running. This leads to use-after-free scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while tunnel-&gt;dprx_work remains active and attempts to dereference tb_tunnel in tb_dp_dprx_work(). A typical race condition is illustrated below: CPU 0 | CPU 1 tb_dp_tunnel_active() | tb_deactivate_and_free_tunnel()| tb_dp_dprx_start() tb_tunnel_deactivate() | queue_delayed_work() tb_dp_activate() | tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker cancel_delayed_work() | tb_tunnel_put(tunnel); | | tunnel = container_of(...); //UAF | tunnel-&gt; //UAF Replacing cancel_delayed_work() with cancel_delayed_work_sync() is not feasible as it would introduce a deadlock: both tb_dp_dprx_work() and the cleanup path acquire tb-&gt;lock, and cancel_delayed_work_sync() would wait indefinitely for the work item that cannot proceed. Instead, implement proper reference counting: - If cancel_delayed_work() returns true (work is pending), we release the reference in the stop function. - If it returns false (work is executing or alre…</p> <p><strong>Affected:</strong> 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 102 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix use-after-free in tb_dp_dprx_work The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(), which does not ensure that the delayed work item tunnel-&gt;dprx_work has fully completed if it was already running. This leads to use-after-free scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while tunnel-&gt;dprx_work remains active and attempts to dereference tb_tunnel in tb_dp_dprx_work(). A typical race condition is illustrated below: CPU 0 | CPU 1 tb_dp_tunnel_active() | tb_deactivate_and_free_tunnel()| tb_dp_dprx_start() tb_tunnel_deactivate() | queue_delayed_work() tb_dp_activate() | tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker cancel_delayed_work() | tb_tunnel_put(tunnel); | | tunnel = container_of(...); //UAF | tunnel-&gt; //UAF Replacing cancel_delayed_work() with cancel_delayed_work_sync() is not feasible as it would introduce a deadlock: both tb_dp_dprx_work() and the cleanup path acquire tb-&gt;lock, and cancel_delayed_work_sync() would wait indefinitely for the work item that cannot proceed. Instead, implement proper reference counting: - If cancel_delayed_work() returns true (work is pending), we release the reference in the stop function. - If it returns false (work is executing or alre…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40002 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2340 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Angriffe durchzuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Angriffe durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2340