CVE-2026-23198
Published: 14 February 2026
Summary
CVE-2026-23198 is a high-severity NULL Pointer Dereference (CWE-476) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 4.7th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified are NIST 800-53 SI-2 (Flaw Remediation) and RA-5 (Vulnerability Monitoring and Scanning).
Threat & Defense at a Glance
Threat & Defense Details
Mitigating Controls (NIST 800-53 r5)AI
Directly requires timely testing and deployment of kernel patches that fix the KVM_IRQFD deassignment clobbering issue, preventing exploitation.
Vulnerability scanning and monitoring identifies deployed Linux kernel versions vulnerable to the KVM IRQFD routing flaw.
System monitoring detects kernel panics, NULL pointer dereferences, or list corruptions from exploitation of the IRQFD deassignment vulnerability.
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Local KVM IRQFD UAF/NULL deref enables kernel exploitation for privilege escalation (T1068) or system DoS via panic (T1499.004).
NVD Description
In the Linux kernel, the following vulnerability has been resolved: KVM: Don't clobber irqfd routing type when deassigning irqfd When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86…
more
and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to handle a concurrent routing update, verify that the irqfd is still active before consuming the routing information. As evidenced by the x86 and arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below), clobbering the entry type without notifying arch code is surprising and error prone. As a bonus, checking that the irqfd is active provides a convenient location for documenting _why_ KVM must not consume the routing entry for an irqfd that is in the process of being deassigned: once the irqfd is deleted from the list (which happens *before* the eventfd is detached), it will no longer receive updates via kvm_irq_routing_update(), and so KVM could deliver an event using stale routing information (relative to KVM_SET_GSI_ROUTING returning to userspace). As an even better bonus, explicitly checking for the irqfd being active fixes a similar bug to the one the clobbering is trying to prevent: if an irqfd is deactivated, and then its routing is changed, kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing() (because the irqfd isn't in the list). And so if the irqfd is in bypass mode, IRQs will continue to be posted using the old routing information. As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type results in KVM incorrectly keeping the IRQ in bypass mode, which is especially problematic on AMD as KVM tracks IRQs that are being posted to a vCPU in a list whose lifetime is tied to the irqfd. Without the help of KASAN to detect use-after-free, the most common sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to the memory for irqfd structure being re-allocated and zeroed, resulting in irqfd->irq_bypass_data being NULL when read by avic_update_iommu_vcpu_affinity(): BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Call Trace: <TASK> avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b </TASK> ---[ end trace 0000000000000000 ]--- If AVIC is inhibited when the irfd is deassigned, the bug will manifest as list corruption, e.g. on the next irqfd assignment. list_add corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:__list_add_valid_or_report+0x97/0xc0 Call Trace: <TASK> avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] kvm_pi_update_irte+0xbf/0x190 [kvm] kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] irq_bypass_register_consumer+0xcd/0x170 [irqbypa ---truncated---
Deeper analysisAI
CVE-2026-23198 is a vulnerability in the Linux kernel's KVM subsystem related to IRQFD handling. Specifically, when deassigning a KVM_IRQFD, the code clobbers the irqfd's copy of the IRQ routing entry, which breaks kvm_arch_irq_bypass_del_producer() on x86 and arm64 architectures by failing to recognize KVM_IRQ_ROUTING_MSI. This issue affects KVM on these platforms, with particularly severe symptoms on AMD systems involving AVIC, leading to NULL pointer dereferences or list corruption due to use-after-free or stale routing data. The vulnerability is classified under CWE-476 (NULL Pointer Dereference) with a CVSS v3.1 score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
A local attacker with low privileges (PR:L) can exploit this vulnerability by interacting with KVM IRQFDs, such as through VFIO or KVM ioctls, during deassignment or concurrent routing updates. Exploitation triggers kernel crashes, including NULL pointer dereferences in functions like amd_iommu_update_ga() or list_add corruption in avic_pi_update_irte(), as seen in oops traces from testing with vfio_irq_test. This results in denial-of-service via kernel panics, with potential for high confidentiality, integrity, and availability impacts due to improper IRQ bypass handling and stale routing delivery.
Mitigation is provided through kernel patches available in stable releases, including commits such as 2284bc168b148a17b5ca3b37b3d95c411f18a08d, 4385b2f2843549bfb932e0dcf76bf4b065543a3c, 6d14ba1e144e796b5fc81044f08cfba9024ca195, 959a063e7f12524bc1871ad1f519787967bbcd45, and b4d37cdb77a0015f51fee083598fa227cc07aaf1. These patches fix the issue by verifying the irqfd remains active before consuming routing information, preventing clobbering and ensuring proper handling during deassignment and updates, thus avoiding bypass mode retention and associated errors.
The vulnerability was identified through kernel debugging tools like KASAN, with reproduction in tainted kernels (e.g., 6.19.0 variants) on Google Arcadia hardware, manifesting as oops during vCPU loads or IRQ assignments. No public evidence of real-world exploitation in the wild is noted.
Details
- CWE(s)