https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-04T09:34:45.754615+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2025-01918 bdu:2025-01918 2026-10-04T09:34:46.081298+00:00 bdu:2025-01918 https://cve.radiocsirt.org/vuln/bell-cve-2024-45030 BELL-CVE-2024-45030 2026-10-04T09:34:46.081356+00:00

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

 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0870 certfr-2024-avi-0870 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at… 2026-10-04T09:34:46.081388+00:00 certfr-2024-avi-0870 https://cve.radiocsirt.org/vuln/cnvd-2024-39474 cnvd-2024-39474 2026-10-04T09:34:46.081405+00:00 cnvd-2024-39474 https://cve.radiocsirt.org/vuln/euvd-2026-346083 EUVD-2026-346083 2026-10-04T09:34:46.081417+00:00 EUVD-2026-346083 https://cve.radiocsirt.org/vuln/fkie_cve-2024-45030 fkie_cve-2024-45030 2026-10-04T09:34:46.081427+00:00

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

igb: cope with large MAX_SKB_FRAGS

Sabrina reports that the igb driver does not cope well with large MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload corruption on TX.

An easy reproducer is to run ssh to connect to the machine. With MAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails. This has been reported originally in https://bugzilla.redhat.com/show_bug.cgi?id=2265320

The root cause of the issue is that the driver does not take into account properly the (possibly large) shared info size when selecting the ring layout, and will try to fit two packets inside the same 4K page even when the 1st fraglist will trump over the 2nd head.

Address the issue by checking if 2K buffers are insufficient.

 https://cve.radiocsirt.org/vuln/ghsa-pc7p-wr8c-6r5f GHSA-pc7p-wr8c-6r5f 2026-10-04T09:34:46.081459+00:00

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

igb: cope with large MAX_SKB_FRAGS

Sabrina reports that the igb driver does not cope well with large MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload corruption on TX.

An easy reproducer is to run ssh to connect to the machine. With MAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails. This has been reported originally in https://bugzilla.redhat.com/show_bug.cgi?id=2265320

The root cause of the issue is that the driver does not take into account properly the (possibly large) shared info size when selecting the ring layout, and will try to fit two packets inside the same 4K page even when the 1st fraglist will trump over the 2nd head.

Address the issue by checking if 2K buffers are insufficient.

 https://cve.radiocsirt.org/vuln/msrc_cve-2024-45030 msrc_CVE-2024-45030 — igb: cope with large MAX_SKB_FRAGS 2026-10-04T09:34:46.081481+00:00 msrc_CVE-2024-45030 https://cve.radiocsirt.org/vuln/oesa-2024-2446 OESA-2024-2446 — kernel security update 2026-10-04T09:34:46.081498+00:00

Affected: openEuler:24.03-LTS: kernel

The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free in do_zone_finish() Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070. BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? btrfs_put_root+0x2d/0x220 [btrfs] ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs] cleaner_kthread+0x21e/0x380 [btrfs] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Allocated by task 3493983: kasan_save_stack+0x33/0…

 https://cve.radiocsirt.org/vuln/suse-su-2024:3551-1 SUSE-SU-2024:3551-1 — Security update for the Linux Kernel 2026-10-04T09:34:46.081670+00:00

Security update for the Linux Kernel

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-45030 UBUNTU-CVE-2024-45030 2026-10-04T09:34:46.081783+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 89 more

In the Linux kernel, the following vulnerability has been resolved: igb: cope with large MAX_SKB_FRAGS Sabrina reports that the igb driver does not cope well with large MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload corruption on TX. An easy reproducer is to run ssh to connect to the machine. With MAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails. This has been reported originally in https://bugzilla.redhat.com/show_bug.cgi?id=2265320 The root cause of the issue is that the driver does not take into account properly the (possibly large) shared info size when selecting the ring layout, and will try to fit two packets inside the same 4K page even when the 1st fraglist will trump over the 2nd head. Address the issue by checking if 2K buffers are insufficient.

 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-2124 WID-SEC-W-2024-2124 — Linux Kernel: Mehrere Schwachstellen 2026-10-04T09:34:46.081928+00:00

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