https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 13 Oct 2026 10:16:24 +0000 https://db.gcve.eu/vuln/bdu:2025-06265 bdu:2025-06265 https://db.gcve.eu/vuln/bdu:2025-06265 https://db.gcve.eu/vuln/certfr-2025-avi-0307 certfr-2025-avi-0307 https://db.gcve.eu/vuln/certfr-2025-avi-0307 https://db.gcve.eu/vuln/fkie_cve-2023-52993 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL</p> <p>Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. It triggers a NULL pointer dereference in the periodic tick code.</p> <p>This happens because the legacy timer interrupt (IRQ0) is resent in software which happens in soft interrupt (tasklet) context. In this context get_irq_regs() returns NULL which leads to the NULL pointer dereference.</p> <p>The reason for the resend is a spurious APIC interrupt on the IRQ0 vector which is captured and leads to a resend when the legacy timer interrupt is enabled. This is wrong because the legacy PIC interrupts are level triggered and therefore should never be resent in software, but nothing ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not know about their trigger type.</p> <p>Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL</p> <p>Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. It triggers a NULL pointer dereference in the periodic tick code.</p> <p>This happens because the legacy timer interrupt (IRQ0) is resent in software which happens in soft interrupt (tasklet) context. In this context get_irq_regs() returns NULL which leads to the NULL pointer dereference.</p> <p>The reason for the resend is a spurious APIC interrupt on the IRQ0 vector which is captured and leads to a resend when the legacy timer interrupt is enabled. This is wrong because the legacy PIC interrupts are level triggered and therefore should never be resent in software, but nothing ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not know about their trigger type.</p> <p>Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.</p> https://db.gcve.eu/vuln/fkie_cve-2023-52993 https://db.gcve.eu/vuln/ghsa-g7hp-hfwm-x3rp <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL</p> <p>Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. It triggers a NULL pointer dereference in the periodic tick code.</p> <p>This happens because the legacy timer interrupt (IRQ0) is resent in software which happens in soft interrupt (tasklet) context. In this context get_irq_regs() returns NULL which leads to the NULL pointer dereference.</p> <p>The reason for the resend is a spurious APIC interrupt on the IRQ0 vector which is captured and leads to a resend when the legacy timer interrupt is enabled. This is wrong because the legacy PIC interrupts are level triggered and therefore should never be resent in software, but nothing ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not know about their trigger type.</p> <p>Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL</p> <p>Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. It triggers a NULL pointer dereference in the periodic tick code.</p> <p>This happens because the legacy timer interrupt (IRQ0) is resent in software which happens in soft interrupt (tasklet) context. In this context get_irq_regs() returns NULL which leads to the NULL pointer dereference.</p> <p>The reason for the resend is a spurious APIC interrupt on the IRQ0 vector which is captured and leads to a resend when the legacy timer interrupt is enabled. This is wrong because the legacy PIC interrupts are level triggered and therefore should never be resent in software, but nothing ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not know about their trigger type.</p> <p>Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.</p> https://db.gcve.eu/vuln/ghsa-g7hp-hfwm-x3rp https://db.gcve.eu/vuln/rhsa-2023:6583 <p>security update for kernel</p> <p>security update for kernel</p> https://db.gcve.eu/vuln/rhsa-2023:6583 https://db.gcve.eu/vuln/rhsa-2024:3421 <p>kernel: netfilter: nf_tables: netlink notifier might race to release objects kernel: netfilter: nf_tables: possible module reference underflow in error path kernel: netfilter: nf_tables: do not allow SET_ID to refer to another table kernel: Use-after-free in nft_verdict_dump due to a race between set GC and transaction kernel: Marvin vulnerability side-channel leakage in the RSA decryption operation kernel: inactive elements in nft_pipapo_walk kernel: netfilter: nftables: exthdr: fix 4-byte stack OOB write kernel: netfilter: nf_tables: don&#39;t skip expired elements during walk kernel: x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL kernel: Linux kernel: Denial of Service in netfilter due to improper garbage collection kernel: netfilter: nft_set_rbtree: fix null deref on element insertion kernel: netfilter: nf_tables: fix underflow in chain reference counter kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function hw: amd: Instruction raise #VC exception at exit hw: amd: Instruction raise #VC exception at exit kernel: mlxsw: spectrum_acl_tcam: Fix stack corruption</p> <p>kernel: netfilter: nf_tables: netlink notifier might race to release objects kernel: netfilter: nf_tables: possible module reference underflow in error path kernel: netfilter: nf_tables: do not allow SET_ID to refer to another table kernel: Use-after-free in nft_verdict_dump due to a race between set GC and transaction kernel: Marvin vulnerability side-channel leakage in the RSA decryption operation kernel: inactive elements in nft_pipapo_walk kernel: netfilter: nftables: exthdr: fix 4-byte stack OOB write kernel: netfilter: nf_tables: don&#39;t skip expired elements during walk kernel: x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL kernel: Linux kernel: Denial of Service in netfilter due to improper garbage collection kernel: netfilter: nft_set_rbtree: fix null deref on element insertion kernel: netfilter: nf_tables: fix underflow in chain reference counter kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function hw: amd: Instruction raise #VC exception at exit hw: amd: Instruction raise #VC exception at exit kernel: mlxsw: spectrum_acl_tcam: Fix stack corruption</p> https://db.gcve.eu/vuln/rhsa-2024:3421 https://db.gcve.eu/vuln/suse-su-2025:01983-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://db.gcve.eu/vuln/suse-su-2025:01983-1 https://db.gcve.eu/vuln/ubuntu-cve-2023-52993 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux and 149 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. It triggers a NULL pointer dereference in the periodic tick code. This happens because the legacy timer interrupt (IRQ0) is resent in software which happens in soft interrupt (tasklet) context. In this context get_irq_regs() returns NULL which leads to the NULL pointer dereference. The reason for the resend is a spurious APIC interrupt on the IRQ0 vector which is captured and leads to a resend when the legacy timer interrupt is enabled. This is wrong because the legacy PIC interrupts are level triggered and therefore should never be resent in software, but nothing ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not know about their trigger type. Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux and 149 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. It triggers a NULL pointer dereference in the periodic tick code. This happens because the legacy timer interrupt (IRQ0) is resent in software which happens in soft interrupt (tasklet) context. In this context get_irq_regs() returns NULL which leads to the NULL pointer dereference. The reason for the resend is a spurious APIC interrupt on the IRQ0 vector which is captured and leads to a resend when the legacy timer interrupt is enabled. This is wrong because the legacy PIC interrupts are level triggered and therefore should never be resent in software, but nothing ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not know about their trigger type. Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.</p> https://db.gcve.eu/vuln/ubuntu-cve-2023-52993 https://db.gcve.eu/vuln/wid-sec-w-2025-0649 <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht spezifizierte Effekte zu erzielen.</p> <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht spezifizierte Effekte zu erzielen.</p> https://db.gcve.eu/vuln/wid-sec-w-2025-0649