https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 12:38:21 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-07988 bdu:2025-07988 https://cve.radiocsirt.org/vuln/bdu:2025-07988 https://cve.radiocsirt.org/vuln/bell-cve-2024-49980 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2024-49980 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0152 certfr-2025-avi-0152 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0152 https://cve.radiocsirt.org/vuln/euvd-2026-313441 EUVD-2026-313441 https://cve.radiocsirt.org/vuln/euvd-2026-313441 https://cve.radiocsirt.org/vuln/fkie_cve-2024-49980 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vrf: revert &#34;vrf: Remove unnecessary RCU-bh critical section&#34;</p> <p>This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.</p> <p>dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following:</p> <p>/* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh();</p> <p>VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning:</p> <p>================================ WARNING: inconsistent lock state 6.11.0 #1 Tainted: G W -------------------------------- inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage. btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 {IN-SOFTIRQ-W} state was registered at: lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 packet_rcv+0xa33/0x1320 __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 __netif_receive_skb_list_core+0x2c9/0x890 netif_receive_skb_list_internal+0x610/0xcc0 [...]</p> <p>other info that might help us debug this: Possible unsafe locking scenario:</p> <p>CPU0 ---- lock(rlock-AF_PACKET); &lt;Interrupt&gt; lock(rlock-AF_PACKET);</p> <p>*** DEADLOCK ***</p> <p>Call Trace: &lt;TASK&gt; dump_stack_lvl+0x73/0xa0 mark_lock+0x102e/0x16b0 __lock_acquire+0x9ae/0x6170 lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vrf: revert &#34;vrf: Remove unnecessary RCU-bh critical section&#34;</p> <p>This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.</p> <p>dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following:</p> <p>/* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh();</p> <p>VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning:</p> <p>================================ WARNING: inconsistent lock state 6.11.0 #1 Tainted: G W -------------------------------- inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage. btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 {IN-SOFTIRQ-W} state was registered at: lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 packet_rcv+0xa33/0x1320 __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 __netif_receive_skb_list_core+0x2c9/0x890 netif_receive_skb_list_internal+0x610/0xcc0 [...]</p> <p>other info that might help us debug this: Possible unsafe locking scenario:</p> <p>CPU0 ---- lock(rlock-AF_PACKET); &lt;Interrupt&gt; lock(rlock-AF_PACKET);</p> <p>*** DEADLOCK ***</p> <p>Call Trace: &lt;TASK&gt; dump_stack_lvl+0x73/0xa0 mark_lock+0x102e/0x16b0 __lock_acquire+0x9ae/0x6170 lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-49980 https://cve.radiocsirt.org/vuln/ghsa-h72j-469c-c787 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vrf: revert &#34;vrf: Remove unnecessary RCU-bh critical section&#34;</p> <p>This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.</p> <p>dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following:</p> <p>/* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh();</p> <p>VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning:</p> <p>================================ WARNING: inconsistent lock state 6.11.0 #1 Tainted: G W -------------------------------- inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage. btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 {IN-SOFTIRQ-W} state was registered at: lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 packet_rcv+0xa33/0x1320 __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 __netif_receive_skb_list_core+0x2c9/0x890 netif_receive_skb_list_internal+0x610/0xcc0 [...]</p> <p>other info that might help us debug this: Possible unsafe locking scenario:</p> <p>CPU0 ---- lock(rlock-AF_PACKET); &lt;Interrupt&gt; lock(rlock-AF_PACKET);</p> <p>*** DEADLOCK ***</p> <p>Call Trace: &lt;TASK&gt; dump_stack_lvl+0x73/0xa0 mark_lock+0x102e/0x16b0 __lock_acquire+0x9ae/0x6170 lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vrf: revert &#34;vrf: Remove unnecessary RCU-bh critical section&#34;</p> <p>This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.</p> <p>dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following:</p> <p>/* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh();</p> <p>VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning:</p> <p>================================ WARNING: inconsistent lock state 6.11.0 #1 Tainted: G W -------------------------------- inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage. btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 {IN-SOFTIRQ-W} state was registered at: lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 packet_rcv+0xa33/0x1320 __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 __netif_receive_skb_list_core+0x2c9/0x890 netif_receive_skb_list_internal+0x610/0xcc0 [...]</p> <p>other info that might help us debug this: Possible unsafe locking scenario:</p> <p>CPU0 ---- lock(rlock-AF_PACKET); &lt;Interrupt&gt; lock(rlock-AF_PACKET);</p> <p>*** DEADLOCK ***</p> <p>Call Trace: &lt;TASK&gt; dump_stack_lvl+0x73/0xa0 mark_lock+0x102e/0x16b0 __lock_acquire+0x9ae/0x6170 lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40…</p> https://cve.radiocsirt.org/vuln/ghsa-h72j-469c-c787 https://cve.radiocsirt.org/vuln/msrc_cve-2024-49980 msrc_CVE-2024-49980 https://cve.radiocsirt.org/vuln/msrc_cve-2024-49980 https://cve.radiocsirt.org/vuln/oesa-2025-1450 <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>ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans</p> <p>There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and size. This would make xlate_pos negative.</p> <p>[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000 [ 23.734158] ================================================================================ [ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7 [ 23.734418] shift exponent -1 is negative</p> <p>Ensuring xlate_pos is a positive or zero before BIT.(CVE-2023-53034)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>f2fs: fix to shrink read extent node in batches</p> <p>We use rwlock to protect core structure data of extent tree during its shrink, however, if there is a huge number of extent nodes in extent tree, during shrink of extent tree, it may hold rwlock for a very long time, which may trigger kernel hang issue.</p> <p>This patch fixes to shrink read extent node in batches, so that, critical region of the rwlock can be shrunk to avoid its extreme long time hold.(CVE-2024-41935)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vrf: revert &amp;quot;vrf: Remove unnecessary RCU-bh critical section&amp;quot;</p> <p>This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.</p> <p>dev_queue_xmit_nit is expe…</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>ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans</p> <p>There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and size. This would make xlate_pos negative.</p> <p>[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000 [ 23.734158] ================================================================================ [ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7 [ 23.734418] shift exponent -1 is negative</p> <p>Ensuring xlate_pos is a positive or zero before BIT.(CVE-2023-53034)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>f2fs: fix to shrink read extent node in batches</p> <p>We use rwlock to protect core structure data of extent tree during its shrink, however, if there is a huge number of extent nodes in extent tree, during shrink of extent tree, it may hold rwlock for a very long time, which may trigger kernel hang issue.</p> <p>This patch fixes to shrink read extent node in batches, so that, critical region of the rwlock can be shrunk to avoid its extreme long time hold.(CVE-2024-41935)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vrf: revert &amp;quot;vrf: Remove unnecessary RCU-bh critical section&amp;quot;</p> <p>This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.</p> <p>dev_queue_xmit_nit is expe…</p> https://cve.radiocsirt.org/vuln/oesa-2025-1450 https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1 <p>kernel-devel-6.11.8-1.1 on GA media</p> <p>kernel-devel-6.11.8-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-49980 <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 91 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: vrf: revert &#34;vrf: Remove unnecessary RCU-bh critical section&#34; This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: ================================ WARNING: inconsistent lock state 6.11.0 #1 Tainted: G W -------------------------------- inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage. btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 {IN-SOFTIRQ-W} state was registered at: lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 packet_rcv+0xa33/0x1320 __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 __netif_receive_skb_list_core+0x2c9/0x890 netif_receive_skb_list_internal+0x610/0xcc0 [...] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(rlock-AF_PACKET); &lt;Interrupt&gt; lock(rlock-AF_PACKET); *** DEADLOCK *** Call Trace: &lt;TASK&gt; dump_stack_lvl+0x73/0xa0 mark_lock+0x102e/0x16b0 __lock_acquire+0x9ae/0x6170 lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 tpacket…</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 91 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: vrf: revert &#34;vrf: Remove unnecessary RCU-bh critical section&#34; This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: ================================ WARNING: inconsistent lock state 6.11.0 #1 Tainted: G W -------------------------------- inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage. btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 {IN-SOFTIRQ-W} state was registered at: lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 packet_rcv+0xa33/0x1320 __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 __netif_receive_skb_list_core+0x2c9/0x890 netif_receive_skb_list_internal+0x610/0xcc0 [...] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(rlock-AF_PACKET); &lt;Interrupt&gt; lock(rlock-AF_PACKET); *** DEADLOCK *** Call Trace: &lt;TASK&gt; dump_stack_lvl+0x73/0xa0 mark_lock+0x102e/0x16b0 __lock_acquire+0x9ae/0x6170 lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 tpacket…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-49980 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251