https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 03:16:41 +0000 https://cve.radiocsirt.org/vuln/alsa-2026:61887 <p><strong>Affected:</strong> AlmaLinux:10: kernel, AlmaLinux:10: kernel-64k, AlmaLinux:10: kernel-64k-core, AlmaLinux:10: kernel-64k-debug, AlmaLinux:10: kernel-64k-debug-core, AlmaLinux:10: kernel-64k-debug-devel, AlmaLinux:10: kernel-64k-debug-devel-matched, AlmaLinux:10: kernel-64k-debug-modules, AlmaLinux:10: kernel-64k-debug-modules-core, AlmaLinux:10: kernel-64k-debug-modules-extra and 65 more</p> <p>The kernel packages contain the Linux kernel, the core of any Linux operating system.</p> <p>Security Fix(es):</p> <p>* kernel: seccomp: passthrough uretprobe systemcall without filtering (CVE-2025-21834) * kernel: ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() (CVE-2026-23003) * kernel: netfilter: nf_tables: Fix for duplicate device in netdev hooks (CVE-2026-43454) * kernel: netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table() (CVE-2026-43450) * kernel: bonding: alb: fix UAF in rlb_arp_recv during bond up/down (CVE-2026-45970) * kernel: ip6_gre: Use cached t-&gt;net in ip6erspan_changelink() (CVE-2026-46120) * kernel: iommu/amd: Fix clone_alias() to use the original device&#39;s devid (CVE-2026-53053) * kernel: NFSD: fix nfs4_file access extra count in nfsd4_add_rdaccess_to_wrdeleg (CVE-2026-53026) * kernel: zram: fix use-after-free in zram_bvec_write_partial() (CVE-2026-53185) * kernel: USB: serial: io_ti: fix heap overflow in get_manuf_info() (CVE-2026-53196) * kernel: mm/huge_memory: update file PMD counter before folio_put() (CVE-2026-53189) * kernel: mm/list_lru: drain before clearing xarray entry on reparent (CVE-2026-53153) * kernel: pNFS: Fix use-after-free in pnfs_update_layout() (CVE-2026-63800) * kernel: nfsd: fix posix_acl leak on SETACL decode failure (CVE-2026-53397) * kernel: nfsd: release layout stid on setlease failure (CVE-2026-53399) * kernel: NFSv4/flexfiles: reject zero filehandle version count (CVE-2026…</p> <p><strong>Affected:</strong> AlmaLinux:10: kernel, AlmaLinux:10: kernel-64k, AlmaLinux:10: kernel-64k-core, AlmaLinux:10: kernel-64k-debug, AlmaLinux:10: kernel-64k-debug-core, AlmaLinux:10: kernel-64k-debug-devel, AlmaLinux:10: kernel-64k-debug-devel-matched, AlmaLinux:10: kernel-64k-debug-modules, AlmaLinux:10: kernel-64k-debug-modules-core, AlmaLinux:10: kernel-64k-debug-modules-extra and 65 more</p> <p>The kernel packages contain the Linux kernel, the core of any Linux operating system.</p> <p>Security Fix(es):</p> <p>* kernel: seccomp: passthrough uretprobe systemcall without filtering (CVE-2025-21834) * kernel: ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() (CVE-2026-23003) * kernel: netfilter: nf_tables: Fix for duplicate device in netdev hooks (CVE-2026-43454) * kernel: netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table() (CVE-2026-43450) * kernel: bonding: alb: fix UAF in rlb_arp_recv during bond up/down (CVE-2026-45970) * kernel: ip6_gre: Use cached t-&gt;net in ip6erspan_changelink() (CVE-2026-46120) * kernel: iommu/amd: Fix clone_alias() to use the original device&#39;s devid (CVE-2026-53053) * kernel: NFSD: fix nfs4_file access extra count in nfsd4_add_rdaccess_to_wrdeleg (CVE-2026-53026) * kernel: zram: fix use-after-free in zram_bvec_write_partial() (CVE-2026-53185) * kernel: USB: serial: io_ti: fix heap overflow in get_manuf_info() (CVE-2026-53196) * kernel: mm/huge_memory: update file PMD counter before folio_put() (CVE-2026-53189) * kernel: mm/list_lru: drain before clearing xarray entry on reparent (CVE-2026-53153) * kernel: pNFS: Fix use-after-free in pnfs_update_layout() (CVE-2026-63800) * kernel: nfsd: fix posix_acl leak on SETACL decode failure (CVE-2026-53397) * kernel: nfsd: release layout stid on setlease failure (CVE-2026-53399) * kernel: NFSv4/flexfiles: reject zero filehandle version count (CVE-2026…</p> https://cve.radiocsirt.org/vuln/alsa-2026:61887 https://cve.radiocsirt.org/vuln/bdu:2025-12026 bdu:2025-12026 https://cve.radiocsirt.org/vuln/bdu:2025-12026 https://cve.radiocsirt.org/vuln/bell-cve-2024-53685 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2024-53685 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0088 certfr-2025-avi-0088 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0088 https://cve.radiocsirt.org/vuln/euvd-2026-313689 EUVD-2026-313689 https://cve.radiocsirt.org/vuln/euvd-2026-313689 https://cve.radiocsirt.org/vuln/fkie_cve-2024-53685 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ceph: give up on paths longer than PATH_MAX</p> <p>If the full path to be built by ceph_mdsc_build_path() happens to be longer than PATH_MAX, then this function will enter an endless (retry) loop, effectively blocking the whole task. Most of the machine becomes unusable, making this a very simple and effective DoS vulnerability.</p> <p>I cannot imagine why this retry was ever implemented, but it seems rather useless and harmful to me. Let&#39;s remove it and fail with ENAMETOOLONG instead.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ceph: give up on paths longer than PATH_MAX</p> <p>If the full path to be built by ceph_mdsc_build_path() happens to be longer than PATH_MAX, then this function will enter an endless (retry) loop, effectively blocking the whole task. Most of the machine becomes unusable, making this a very simple and effective DoS vulnerability.</p> <p>I cannot imagine why this retry was ever implemented, but it seems rather useless and harmful to me. Let&#39;s remove it and fail with ENAMETOOLONG instead.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-53685 https://cve.radiocsirt.org/vuln/ghsa-32jq-w4j4-wjvc <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ceph: give up on paths longer than PATH_MAX</p> <p>If the full path to be built by ceph_mdsc_build_path() happens to be longer than PATH_MAX, then this function will enter an endless (retry) loop, effectively blocking the whole task. Most of the machine becomes unusable, making this a very simple and effective DoS vulnerability.</p> <p>I cannot imagine why this retry was ever implemented, but it seems rather useless and harmful to me. Let&#39;s remove it and fail with ENAMETOOLONG instead.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ceph: give up on paths longer than PATH_MAX</p> <p>If the full path to be built by ceph_mdsc_build_path() happens to be longer than PATH_MAX, then this function will enter an endless (retry) loop, effectively blocking the whole task. Most of the machine becomes unusable, making this a very simple and effective DoS vulnerability.</p> <p>I cannot imagine why this retry was ever implemented, but it seems rather useless and harmful to me. Let&#39;s remove it and fail with ENAMETOOLONG instead.</p> https://cve.radiocsirt.org/vuln/ghsa-32jq-w4j4-wjvc https://cve.radiocsirt.org/vuln/oesa-2026-1228 <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net: fec: remove .ndo_poll_controller to avoid deadlocks</p> <p>There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (&amp;quot;eth: sungem: remove .ndo_poll_controller to avoid deadlocks&amp;quot;). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.(CVE-2024-38553)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ceph: give up on paths longer than PATH_MAX</p> <p>If the full path to be built by ceph_mdsc_build_path() happens to be longer than PATH_MAX, then this function will enter an endless (retry) loop, effectively blocking the whole task. Most of the machine becomes unusable, making this a very simple and effective DoS vulnerability.</p> <p>I cannot imagine why this retry was ever implemented, but it seems rather useless and harmful to me. Let&amp;apos;s remove it and fail with ENAMETOOLONG instead.(CVE-2024-53685)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Bluetooth: hc…</p> <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net: fec: remove .ndo_poll_controller to avoid deadlocks</p> <p>There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (&amp;quot;eth: sungem: remove .ndo_poll_controller to avoid deadlocks&amp;quot;). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.(CVE-2024-38553)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ceph: give up on paths longer than PATH_MAX</p> <p>If the full path to be built by ceph_mdsc_build_path() happens to be longer than PATH_MAX, then this function will enter an endless (retry) loop, effectively blocking the whole task. Most of the machine becomes unusable, making this a very simple and effective DoS vulnerability.</p> <p>I cannot imagine why this retry was ever implemented, but it seems rather useless and harmful to me. Let&amp;apos;s remove it and fail with ENAMETOOLONG instead.(CVE-2024-53685)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Bluetooth: hc…</p> https://cve.radiocsirt.org/vuln/oesa-2026-1228 https://cve.radiocsirt.org/vuln/suse-su-2025:0289-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2025:0289-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-53685 <p><strong>Affected:</strong> 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 196 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: ceph: give up on paths longer than PATH_MAX If the full path to be built by ceph_mdsc_build_path() happens to be longer than PATH_MAX, then this function will enter an endless (retry) loop, effectively blocking the whole task. Most of the machine becomes unusable, making this a very simple and effective DoS vulnerability. I cannot imagine why this retry was ever implemented, but it seems rather useless and harmful to me. Let&#39;s remove it and fail with ENAMETOOLONG instead.</p> <p><strong>Affected:</strong> 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 196 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: ceph: give up on paths longer than PATH_MAX If the full path to be built by ceph_mdsc_build_path() happens to be longer than PATH_MAX, then this function will enter an endless (retry) loop, effectively blocking the whole task. Most of the machine becomes unusable, making this a very simple and effective DoS vulnerability. I cannot imagine why this retry was ever implemented, but it seems rather useless and harmful to me. Let&#39;s remove it and fail with ENAMETOOLONG instead.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-53685 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0047 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen und weitere nicht spezifizierte Angriffe zu starten.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen und weitere nicht spezifizierte Angriffe zu starten.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0047