data built 2026-10-19T13:16:53Z

Look up another CVE · open CVE-2026-63806 in the interactive tracker

CVE-2026-63806

KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned()

7.1 EPSS 0.2% AV:L

Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem virt/kvm. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-63806 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

ReleaseStatus VersionWhat this means
Debian 12bookwormfixedDLA-4720-1 · 2026-08-05 · text6.1.180-1Update the kernel and reboot. DLA-4720-1 shipped the fix on 2026-08-05, in 6.1.180-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixiefixed6.12.95-1Update the kernel and reboot. Fixed in 6.12.95-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed7.1.3-1Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed7.1.3-1Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: <TASK> __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf </TASK> Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on "normal" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

virt/kvm/eventfd.c

What this is
KERNEL VIRTUAL MACHINE (KVM)MAINTAINERS section matched on virt/kvm/* · kvm@vger.kernel.org · Supported
Show whether Debian builds this, per release

Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.

  • bookworm, trixie, forky, sid?
?
not established - no Makefile entry for the affected file

Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS

Signals

Published
2026-07-19 (3 months ago)source
CVSS
7.1 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:Hsource recompute it
Attack vector
local (AV:L)source
EPSS
0.15%, higher than 4.2% of all CVEssource
CISA KEV
not listedthe KEV catalogue
Debian urgency
not yet assignedsource
Subsystem
virt/kvm

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

IntroducedFixed inCommit
2.6.325.10.2612426c15c1395
2.6.325.15.2124186c8507899
2.6.326.1.17836ff44fb3d89
2.6.326.6.14592fc631b69de
2.6.326.12.95bf89e3738480
2.6.326.18.385da9b1a87ec7
2.6.327.1.35c87b4737468
2.6.327.2f1edbed787ba

Debian advisories

AdvisoryDateShipped toDebian
DLA-4723-12026-08-07bullseye 6.1.180-1~deb11u1tracker
DLA-4720-12026-08-05bookworm 6.1.180-1tracker
DLA-4717-12026-08-05bullseye 5.10.262-1tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local
A malicious KVM guest triggers this via guest-executed MMIO stores handled by the x86 instruction emulator (KVM_RUN → vmx_handle_exit → kvm_mmu_page_fault → x86_emulate_instruction → emulator_read_write → vcpu_mmio_write → ioeventfd_write), not via remote network input to the host.
AC:LAttack complexity, low
The guest fully controls the spanning store address, size, and timing; with standard QEMU/virtio datamatch ioeventfd MMIO layouts, a page-boundary write reliably reaches ioeventfd_in_range() with a misaligned val pointer and fires the BUG_ON().
PR:NPrivileges required, none
Exploitation requires only unprivileged code execution inside an already-running guest VM (reproducer ran as UID 1000); no host capabilities, KVM ioctls, or guest root are needed beyond what any cloud VM tenant or compromised guest process already has.
UI:NUser interaction, none
No victim interaction is required once the attacker can run code in a KVM guest with a datamatch ioeventfd configured, which is the default virtio/QEMU setup.
S:CScope, changed
The vulnerable component is the host kernel KVM subsystem, but exploitation is initiated from a guest VM and causes a host kernel BUG/oops, crossing the hypervisor security boundary.
C:NConfidentiality impact, none
The failure mode is an explicit BUG_ON() alignment check before any datamatch comparison; there is no out-of-bounds read, use-after-free, or other memory corruption that could disclose host data.
I:NIntegrity impact, none
The bug triggers a deliberate kernel BUG and does not corrupt or modify host memory; it is a crash-only denial-of-service with no integrity impact.
A:HAvailability impact, high
A guest-triggered BUG_ON() in ioeventfd_write() causes a host kernel oops/panic, denying availability of the entire physical host and all co-resident VMs on multi-tenant KVM hypervisors.