{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.105-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.8-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux-6.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.107-1~deb12u1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs  Cancel (and flush) the I/O APIC's delayed EOI handling work during the \"pre VM destroy\" phase, before vCPUs are destroyed, as processing the EOI broadcast will inject another IRQ if the line is asserted, i.e. will try to deliver an IRQ to the target vCPU(s).  Canceling the work after vCPUs are destroyed leads to UAF if the delayed work is processed after vCPUs are destroyed.    BUG: KASAN: slab-use-after-free in __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250   Read of size 8 at addr ffff8880499abea0 by task kworker/1:2/1218    CPU: 1 UID: 0 PID: 1218 Comm: kworker/1:2 Not tainted 7.1.0-rc7 #5 PREEMPT(lazy)   Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014   Workqueue: events kvm_ioapic_eoi_inject_work   Call Trace:    \u003cTASK\u003e    __dump_stack lib/dump_stack.c:94    dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120    print_address_description mm/kasan/report.c:378    print_report+0x139/0x4ad mm/kasan/report.c:482    kasan_report+0xe4/0x1d0 mm/kasan/report.c:595    __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250    __kvm_irq_delivery_to_apic+0xd8/0xbf0 arch/x86/kvm/lapic.c:1345    kvm_irq_delivery_to_apic arch/x86/kvm/lapic.h:129    ioapic_service+0x308/0x590 arch/x86/kvm/ioapic.c:492    kvm_ioapic_eoi_inject_work+0x13c/0x190 arch/x86/kvm/ioapic.c:532    process_one_work+0xa59/0x19a0 kernel/workqueue.c:3314    process_scheduled_works kernel/workqueue.c:3397    worker_thread+0x5eb/0xe50 kernel/workqueue.c:3478    kthread+0x370/0x450 kernel/kthread.c:436    ret_from_fork+0x72b/0xd30 arch/x86/kernel/process.c:158    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245    \u003c/TASK\u003e  Note, the VM is unreachable once kvm_destroy_vm() starts, and scheduling new work via kvm_ioapic_send_eoi() can only be done via KVM_RUN, i.e. requires a live vCPU.  Alternatively, KVM could simply destroy the I/O APIC during the \"pre\" phase of VM destruction, but that gets more than a bit sketchy as KVM expects the I/O APIC to exist if ioapic_in_kernel() is true, and nested virtualization in particular has a bad habit of touching VM-scope state during vCPU destruction.  E.g. attempting to free the PIC during the pre phase would lead to a NULL pointer dereference in kvm_cpu_has_extint(), and it's not hard to imagine the I/O APIC having a similar flaw.",
  "id": "DEBIAN-CVE-2026-74517",
  "modified": "2026-09-19T21:47:23.077149666Z",
  "published": "2026-08-15T13:17:56.850Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-74517"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-74517"
  ]
}