https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 02:47:26 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-11843 bdu:2026-11843 https://cve.radiocsirt.org/vuln/bdu:2026-11843 https://cve.radiocsirt.org/vuln/bell-cve-2026-23313 <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-2026-23313 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0548 certfr-2026-avi-0548 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0548 https://cve.radiocsirt.org/vuln/euvd-2026-315466 EUVD-2026-315466 https://cve.radiocsirt.org/vuln/euvd-2026-315466 https://cve.radiocsirt.org/vuln/fkie_cve-2026-23313 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>i40e: Fix preempt count leak in napi poll tracepoint</p> <p>Using get_cpu() in the tracepoint assignment causes an obvious preempt count leak because nothing invokes put_cpu() to undo it:</p> <p>softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?</p> <p>This clearly has seen a lot of testing in the last 3+ years...</p> <p>Use smp_processor_id() instead.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>i40e: Fix preempt count leak in napi poll tracepoint</p> <p>Using get_cpu() in the tracepoint assignment causes an obvious preempt count leak because nothing invokes put_cpu() to undo it:</p> <p>softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?</p> <p>This clearly has seen a lot of testing in the last 3+ years...</p> <p>Use smp_processor_id() instead.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-23313 https://cve.radiocsirt.org/vuln/ghsa-94ww-55m5-gmrg <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>i40e: Fix preempt count leak in napi poll tracepoint</p> <p>Using get_cpu() in the tracepoint assignment causes an obvious preempt count leak because nothing invokes put_cpu() to undo it:</p> <p>softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?</p> <p>This clearly has seen a lot of testing in the last 3+ years...</p> <p>Use smp_processor_id() instead.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>i40e: Fix preempt count leak in napi poll tracepoint</p> <p>Using get_cpu() in the tracepoint assignment causes an obvious preempt count leak because nothing invokes put_cpu() to undo it:</p> <p>softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?</p> <p>This clearly has seen a lot of testing in the last 3+ years...</p> <p>Use smp_processor_id() instead.</p> https://cve.radiocsirt.org/vuln/ghsa-94ww-55m5-gmrg https://cve.radiocsirt.org/vuln/msrc_cve-2026-23313 msrc_CVE-2026-23313 https://cve.radiocsirt.org/vuln/msrc_cve-2026-23313 https://cve.radiocsirt.org/vuln/oesa-2026-2418 <p><strong>Affected:</strong> openEuler:24.03-LTS-SP1: 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:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL. So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0…</p> <p><strong>Affected:</strong> openEuler:24.03-LTS-SP1: 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:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL. So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0…</p> https://cve.radiocsirt.org/vuln/oesa-2026-2418 https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-1 https://cve.radiocsirt.org/vuln/suse-su-2026:21834-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2026:21834-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23313 <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 140 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: i40e: Fix preempt count leak in napi poll tracepoint Using get_cpu() in the tracepoint assignment causes an obvious preempt count leak because nothing invokes put_cpu() to undo it: softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101? This clearly has seen a lot of testing in the last 3+ years... Use smp_processor_id() instead.</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 140 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: i40e: Fix preempt count leak in napi poll tracepoint Using get_cpu() in the tracepoint assignment causes an obvious preempt count leak because nothing invokes put_cpu() to undo it: softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101? This clearly has seen a lot of testing in the last 3+ years... Use smp_processor_id() instead.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23313 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0861 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, weitere nicht spezifizierte Auswirkungen zu verursachen und potentiell Code auszuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, weitere nicht spezifizierte Auswirkungen zu verursachen und potentiell Code auszuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0861