CVEvulnerability
CVE-2026-98283
8.8 HIGH
Official page ↗
- Status
- Received
- Published
- 2026-10-06
- Last modified
- 2026-10-19
- Assigner
- 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- CVSS 3.1 (416baaa9-dc9f-4396-8d5f-8c081fb06d67)
- 8.8 HIGH — CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Description
In the Linux kernel, the following vulnerability has been resolved:
KVM: PPC: Book3S HV: fix use-after-free in kvmhv_emulate_tlbie_all_lpid()
kvmhv_emulate_tlbie_all_lpid() iterates the nested-guest IDR and drops
mmu_lock before calling kvmhv_emulate_tlbie_lpid(), but does not hold a
reference on the kvm_nested_guest pointer obtained from the IDR. A
concurrent vCPU issuing a single-LPID tlbie (is=2, ric=2) can race
through kvmhv_flush_nested() -> kvmhv_remove_nested() -> idr_remove /
--refcnt -> kvmhv_release_nested() -> kfree(gp) in that window, leaving
the iterating vCPU with a dangling pointer. The subsequent
mutex_lock(&gp->tlb_lock) and accesses to gp->shadow_pgtable,
gp->shadow_lpid and gp->l1_host all touch freed memory. The free path
is fully L1-controlled.
Fix this by incrementing gp->refcnt inside the loop before dropping
mmu_lock, mirroring what kvmhv_get_nested() does, and releasing the
reference with kvmhv_put_nested() after the per-guest work completes.
This is the same get/put discipline already used at every other
call site that drops mmu_lock while holding a nested-guest pointer.
References
- https://git.kernel.org/stable/c/24b634852413229bb8340d908b115c3365f3a247 git.kernel.org
- https://git.kernel.org/stable/c/4d8f7b1f586375df8bce23a0909566ad5e852259 git.kernel.org
- https://git.kernel.org/stable/c/51938dfa8a51a4f85328413fca9b6e21f9d2d088 git.kernel.org
- https://git.kernel.org/stable/c/e37fba1ba69385cff2d0e60b371ee19e7d1852d1 git.kernel.org
- https://git.kernel.org/stable/c/ec2d7a52b3996ae81131617b4afc0af31583c1b4 git.kernel.org
- https://git.kernel.org/stable/c/fbf69b7d0555ee83c871f58750770f74b7179ad1 git.kernel.org