https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 01:27:13 +0000 https://cve.radiocsirt.org/vuln/alsa-2025:8643 <p><strong>Affected:</strong> AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core, AlmaLinux:9: kernel-64k-debug-modules-extra and 66 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: net: gso: fix ownership in __udp_gso_segment (CVE-2025-21926) * kernel: vlan: enforce underlying device type (CVE-2025-21920) * kernel: xsk: fix an integer overflow in xp_create_and_assign_umem() (CVE-2025-21997) * kernel: net: fix geneve_opt length integer overflow (CVE-2025-22055) * kernel: ext4: fix OOB read when checking dotdot dir (CVE-2025-37785) * kernel: wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi (CVE-2025-37943)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> <p><strong>Affected:</strong> AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core, AlmaLinux:9: kernel-64k-debug-modules-extra and 66 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: net: gso: fix ownership in __udp_gso_segment (CVE-2025-21926) * kernel: vlan: enforce underlying device type (CVE-2025-21920) * kernel: xsk: fix an integer overflow in xp_create_and_assign_umem() (CVE-2025-21997) * kernel: net: fix geneve_opt length integer overflow (CVE-2025-22055) * kernel: ext4: fix OOB read when checking dotdot dir (CVE-2025-37785) * kernel: wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi (CVE-2025-37943)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> https://cve.radiocsirt.org/vuln/alsa-2025:8643 https://cve.radiocsirt.org/vuln/bdu:2025-03891 bdu:2025-03891 https://cve.radiocsirt.org/vuln/bdu:2025-03891 https://cve.radiocsirt.org/vuln/bell-cve-2025-21920 <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-2025-21920 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0333 certfr-2025-avi-0333 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0333 https://cve.radiocsirt.org/vuln/euvd-2026-314097 EUVD-2026-314097 https://cve.radiocsirt.org/vuln/euvd-2026-314097 https://cve.radiocsirt.org/vuln/fkie_cve-2025-21920 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vlan: enforce underlying device type</p> <p>Currently, VLAN devices can be created on top of non-ethernet devices.</p> <p>Besides the fact that it doesn&#39;t make much sense, this also causes a bug which leaks the address of a kernel function to usermode.</p> <p>When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device.</p> <p>As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add.</p> <p>__dev_mc_add uses dev-&gt;addr_len to determine the length of the new multicast address.</p> <p>This causes an out-of-bounds read if dev-&gt;addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long.</p> <p>This behaviour can be reproduced using the following commands:</p> <p>ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100</p> <p>Then, the following command will display the address of garp_pdu_rcv:</p> <p>ip maddr show | grep 01:80:c2:00:00:21</p> <p>Fix the bug by enforcing the type of the underlying device during VLAN device initialization.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vlan: enforce underlying device type</p> <p>Currently, VLAN devices can be created on top of non-ethernet devices.</p> <p>Besides the fact that it doesn&#39;t make much sense, this also causes a bug which leaks the address of a kernel function to usermode.</p> <p>When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device.</p> <p>As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add.</p> <p>__dev_mc_add uses dev-&gt;addr_len to determine the length of the new multicast address.</p> <p>This causes an out-of-bounds read if dev-&gt;addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long.</p> <p>This behaviour can be reproduced using the following commands:</p> <p>ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100</p> <p>Then, the following command will display the address of garp_pdu_rcv:</p> <p>ip maddr show | grep 01:80:c2:00:00:21</p> <p>Fix the bug by enforcing the type of the underlying device during VLAN device initialization.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-21920 https://cve.radiocsirt.org/vuln/ghsa-p79h-jcrm-6qrc <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vlan: enforce underlying device type</p> <p>Currently, VLAN devices can be created on top of non-ethernet devices.</p> <p>Besides the fact that it doesn&#39;t make much sense, this also causes a bug which leaks the address of a kernel function to usermode.</p> <p>When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device.</p> <p>As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add.</p> <p>__dev_mc_add uses dev-&gt;addr_len to determine the length of the new multicast address.</p> <p>This causes an out-of-bounds read if dev-&gt;addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long.</p> <p>This behaviour can be reproduced using the following commands:</p> <p>ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100</p> <p>Then, the following command will display the address of garp_pdu_rcv:</p> <p>ip maddr show | grep 01:80:c2:00:00:21</p> <p>Fix the bug by enforcing the type of the underlying device during VLAN device initialization.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vlan: enforce underlying device type</p> <p>Currently, VLAN devices can be created on top of non-ethernet devices.</p> <p>Besides the fact that it doesn&#39;t make much sense, this also causes a bug which leaks the address of a kernel function to usermode.</p> <p>When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device.</p> <p>As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add.</p> <p>__dev_mc_add uses dev-&gt;addr_len to determine the length of the new multicast address.</p> <p>This causes an out-of-bounds read if dev-&gt;addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long.</p> <p>This behaviour can be reproduced using the following commands:</p> <p>ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100</p> <p>Then, the following command will display the address of garp_pdu_rcv:</p> <p>ip maddr show | grep 01:80:c2:00:00:21</p> <p>Fix the bug by enforcing the type of the underlying device during VLAN device initialization.</p> https://cve.radiocsirt.org/vuln/ghsa-p79h-jcrm-6qrc https://cve.radiocsirt.org/vuln/msrc_cve-2025-21920 msrc_CVE-2025-21920 https://cve.radiocsirt.org/vuln/msrc_cve-2025-21920 https://cve.radiocsirt.org/vuln/oesa-2025-1874 <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>pfifo_tail_enqueue: Drop new packet when sch-&amp;gt;limit == 0</p> <p>Expected behaviour: In case we reach scheduler&amp;apos;s limit, pfifo_tail_enqueue() will drop a packet in scheduler&amp;apos;s queue and decrease scheduler&amp;apos;s qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler&amp;apos;s qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code.</p> <p>Weird behaviour: In case we set `sch-&amp;gt;limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the &amp;apos;drop a packet&amp;apos; step will do nothing. This means the scheduler&amp;apos;s qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler&amp;apos;s qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code.</p> <p>The problem is: Let&amp;apos;s say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A&amp;apos;s type must have &amp;apos;-&amp;gt;graft()&amp;apos; function to create parent/child relationship. Let&amp;apos;s say Qdisc_A&amp;apos;s type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B&amp;apos;s type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured to have `sch-&amp;gt;limit == 0`. - Qdisc_A is configured to route the enqueued&amp;apos;s packet to Qdisc_B.</p> <p>Enqueue packet through…</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>pfifo_tail_enqueue: Drop new packet when sch-&amp;gt;limit == 0</p> <p>Expected behaviour: In case we reach scheduler&amp;apos;s limit, pfifo_tail_enqueue() will drop a packet in scheduler&amp;apos;s queue and decrease scheduler&amp;apos;s qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler&amp;apos;s qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code.</p> <p>Weird behaviour: In case we set `sch-&amp;gt;limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the &amp;apos;drop a packet&amp;apos; step will do nothing. This means the scheduler&amp;apos;s qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler&amp;apos;s qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code.</p> <p>The problem is: Let&amp;apos;s say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A&amp;apos;s type must have &amp;apos;-&amp;gt;graft()&amp;apos; function to create parent/child relationship. Let&amp;apos;s say Qdisc_A&amp;apos;s type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B&amp;apos;s type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured to have `sch-&amp;gt;limit == 0`. - Qdisc_A is configured to route the enqueued&amp;apos;s packet to Qdisc_B.</p> <p>Enqueue packet through…</p> https://cve.radiocsirt.org/vuln/oesa-2025-1874 https://cve.radiocsirt.org/vuln/rhsa-2025:8643 <p>kernel: vlan: enforce underlying device type kernel: net: gso: fix ownership in __udp_gso_segment kernel: xsk: fix an integer overflow in xp_create_and_assign_umem() kernel: net: fix geneve_opt length integer overflow kernel: ext4: fix OOB read when checking dotdot dir kernel: wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi</p> <p>kernel: vlan: enforce underlying device type kernel: net: gso: fix ownership in __udp_gso_segment kernel: xsk: fix an integer overflow in xp_create_and_assign_umem() kernel: net: fix geneve_opt length integer overflow kernel: ext4: fix OOB read when checking dotdot dir kernel: wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi</p> https://cve.radiocsirt.org/vuln/rhsa-2025:8643 https://cve.radiocsirt.org/vuln/suse-su-2025:02249-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:02249-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21920 <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 201 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: vlan: enforce underlying device type Currently, VLAN devices can be created on top of non-ethernet devices. Besides the fact that it doesn&#39;t make much sense, this also causes a bug which leaks the address of a kernel function to usermode. When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device. As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add. __dev_mc_add uses dev-&gt;addr_len to determine the length of the new multicast address. This causes an out-of-bounds read if dev-&gt;addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long. This behaviour can be reproduced using the following commands: ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100 Then, the following command will display the address of garp_pdu_rcv: ip maddr show | grep 01:80:c2:00:00:21 Fix the bug by enforcing the type of the underlying device during VLAN device initialization.</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 201 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: vlan: enforce underlying device type Currently, VLAN devices can be created on top of non-ethernet devices. Besides the fact that it doesn&#39;t make much sense, this also causes a bug which leaks the address of a kernel function to usermode. When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device. As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add. __dev_mc_add uses dev-&gt;addr_len to determine the length of the new multicast address. This causes an out-of-bounds read if dev-&gt;addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long. This behaviour can be reproduced using the following commands: ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100 Then, the following command will display the address of garp_pdu_rcv: ip maddr show | grep 01:80:c2:00:00:21 Fix the bug by enforcing the type of the underlying device during VLAN device initialization.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21920 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0683 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial-of-Service auszulösen und um nicht näher spezifizierte Auswirkungen zu erzielen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial-of-Service auszulösen und um nicht näher spezifizierte Auswirkungen zu erzielen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0683