https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-04T16:32:31.545380+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2026-04481 bdu:2026-04481 2026-10-04T16:32:31.555187+00:00 bdu:2026-04481 https://cve.radiocsirt.org/vuln/bell-cve-2024-35793 BELL-CVE-2024-35793 2026-10-04T16:32:31.555258+00:00

Affected: Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0546 certfr-2024-avi-0546 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a… 2026-10-04T16:32:31.555303+00:00 certfr-2024-avi-0546 https://cve.radiocsirt.org/vuln/euvd-2026-345655 EUVD-2026-345655 2026-10-04T16:32:31.555324+00:00 EUVD-2026-345655 https://cve.radiocsirt.org/vuln/fkie_cve-2024-35793 fkie_cve-2024-35793 2026-10-04T16:32:31.555336+00:00

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

debugfs: fix wait/cancellation handling during remove

Ben Greear further reports deadlocks during concurrent debugfs remove while files are being accessed, even though the code in question now uses debugfs cancellations. Turns out that despite all the review on the locking, we missed completely that the logic is wrong: if the refcount hits zero we can finish (and need not wait for the completion), but if it doesn't we have to trigger all the cancellations. As written, we can _never_ get into the loop triggering the cancellations. Fix this, and explain it better while at it.

 https://cve.radiocsirt.org/vuln/ghsa-pv8w-5hmg-8mf4 GHSA-pv8w-5hmg-8mf4 2026-10-04T16:32:31.555369+00:00

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

debugfs: fix wait/cancellation handling during remove

Ben Greear further reports deadlocks during concurrent debugfs remove while files are being accessed, even though the code in question now uses debugfs cancellations. Turns out that despite all the review on the locking, we missed completely that the logic is wrong: if the refcount hits zero we can finish (and need not wait for the completion), but if it doesn't we have to trigger all the cancellations. As written, we can _never_ get into the loop triggering the cancellations. Fix this, and explain it better while at it.

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-35793 UBUNTU-CVE-2024-35793 2026-10-04T16:32:31.555394+00:00

Affected: 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 68 more

In the Linux kernel, the following vulnerability has been resolved: debugfs: fix wait/cancellation handling during remove Ben Greear further reports deadlocks during concurrent debugfs remove while files are being accessed, even though the code in question now uses debugfs cancellations. Turns out that despite all the review on the locking, we missed completely that the logic is wrong: if the refcount hits zero we can finish (and need not wait for the completion), but if it doesn't we have to trigger all the cancellations. As written, we can _never_ get into the loop triggering the cancellations. Fix this, and explain it better while at it.

 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1188 WID-SEC-W-2024-1188 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service 2026-10-04T16:32:31.555516+00:00

Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.