Look up another CVE · open CVE-2026-89908 in the interactive tracker
CVE-2026-89908
LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem arch/loongarch. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89908 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
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE, only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every other change. But the generic code allocates a zeroed memslot for every change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update, e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active memslot has arch.flags == 0. With both flags clear, fault_supports_huge_mapping() falls through to the alignment check on the HVA range alone, which no longer verifies that the GPA and HVA have the same offset within a PMD. A memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can then be mapped with PMD entries on read faults, and since kvm_map_page() aligns the gfn and the pfn independently, the guest ends up accessing the wrong host pages, exactly the "d -> f, e -> g" case described in the comment above the check. Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY, as the GPA, HVA and size are guaranteed to be unchanged for that case.
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.
arch/loongarch/kvm/mmu.c
- What this is
- KERNEL VIRTUAL MACHINE FOR LOONGARCH (KVM/LoongArch)MAINTAINERS section matched on arch/loongarch/kvm/ · kvm@vger.kernel.org · Maintained
- Kernel module
- kvm
Check it on the machine
grep -w CONFIG_KVM /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w kvmPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- trixieBnot built on armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- forky, sidBnot built on armhf/armmp, armhf/armmp-lpae
- bookworm · linux-6.12Bnot built on armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- ?
- not established - no Makefile entry for the affected file
- B
- built in on some, a module on others, absent on the rest
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.
- Build switch
- CONFIG_KVM
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 kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-16 (33 days ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- arch/loongarch
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.8 | 6.12.110 | 7c6df65b5384 |
| 6.8 | 6.18.51 | 4e4dbc341b15 |
| 6.8 | 7.2.5 | bc7a6849b439 |
| 6.8 | 7.3 | 27a9bfee3bbc |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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
- The bug is reached from a LoongArch KVM guest page fault on the host KVM_RUN path (kvm_arch_vcpu_ioctl_run -> kvm_handle_exit -> kvm_handle_fault -> kvm_handle_mm_fault -> kvm_map_page) after KVM_SET_USER_MEMORY_REGION FLAGS_ONLY; there is no network or physical path.
- AC:LAttack complexity, low
- After FLAGS_ONLY zeros memslot arch.flags, a guest load to an interior GPA of a GPA/HVA-offset-mismatched slot with host THP backing deterministically installs a PMD because kvm_map_page aligns gfn and pfn independently; the VMM chooses the memslot and dirty-log toggle, and THP is a common default, not a rare config or uncontrolled race.
- PR:LPrivileges required, low
- A tenant guest or a host kvm-group user running QEMU is sufficient: /dev/kvm and kvm_vm_ioctl() have no capable() check, and the fault path has none either. Init-namespace root is not required, so this is Low rather than High.
- UI:NUser interaction, none
- The attacker guest issues the faulting load or store itself during KVM_RUN; no separate victim action such as mounting a filesystem, opening a crafted file, or confirming a prompt is required.
- S:CScope, changed
- kvm_map_page installs stage-2 PMD entries that bind guest GPAs to the wrong host PFNs, breaking the hypervisor GPA-to-HVA contract and crossing the KVM guest-to-host isolation boundary, which CNA guidance rates Changed for KVM guest-to-host escape.
- C:HConfidentiality impact, high
- On read faults, fault_supports_huge_mapping() allows a PMD that maps the guest onto the wrong host pages (the commit's d->f, e->g case), giving the guest an unauthorized read of the host physical pages backing that 2MB block.
- I:HIntegrity impact, high
- After dirty logging is toggled off (another FLAGS_ONLY that also leaves arch.flags at 0), write faults install writable huge mappings to those same wrong host PFNs, so the guest can modify host pages the memslot did not bind to that GPA.
- A:HAvailability impact, high
- Aliased stage-2 PMDs scramble guest RAM and, during live migration, produce a corrupted destination image that can crash the VM; incorrect huge PFNs can also oops the host if the aligned range is not valid RAM, denying service to the hypervisor and co-located VMs.