Answer in brief
CVE-2026-89913 records a Unknown severity vulnerability in KVM: arm64: vgic-v3: take an LPI reference in vgic_v3_save_pending_tables. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <7631f95297560157d3a9283cb999e3be00103348 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <d3a2d20b7248ea67465af1cf79c79f90ff70926c || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <f5b8f203bfc07a5a257dff859e66d2c500f9f509 || >=0 <6.18.51 || >=0 <7.2.5 | 7631f95297560157d3a9283cb999e3be00103348, d3a2d20b7248ea67465af1cf79c79f90ff70926c, f5b8f203bfc07a5a257dff859e66d2c500f9f509, 6.18.51, 7.2.5 |
Published upstream
Sep 16, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 16, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 16, 2026
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-v3: take an LPI reference in vgic_v3_save_pending_tables vgic_v3_save_pending_tables() iterates dist->lpi_xa using xa_for_each() and dereferences the returned struct vgic_irq in the loop body without holding a reference on the LPI. The xarray iterator only provides temporary RCU coverage while looking up the current entry. That is not sufficient for this loop body, which reads fields from struct vgic_irq and performs guest memory accesses before the iteration completes. A concurrent path can trigger this race: the irqfd cached injection path (vgic_its_inject_cached_translation) obtains a transient LPI reference via vgic_its_check_cache() without holding kvm->lock, vcpu->mutex, config_lock, or its_lock. If guest ITS DISCARD then drops the cache and ITE references under its_lock, the transient inject reference may become the final one. When vgic_put_irq() drops it, the LPI is erased from lpi_xa and freed via kfree_rcu(). Meanwhile, vgic_v3_save_pending_tables() may still hold a stale pointer obtained from the xarray iterator and dereference it after the RCU grace period completes. Fix this by re-fetching each iterated LPI via vgic_get_irq(), which takes a stable reference, and dropping it with vgic_put_irq() on all paths. This matches the pattern already used by other lpi_xa iterators in the vgic ITS code.
Quoted source text, attributed separately from HOL analysis.