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 callin…

Overview

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.

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

Vendor advisories

• Red Hat VEX · Moderate · affected: Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 8, Red Hat OpenShift Container Platform 4 · no fix planned: Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 8, Red Hat OpenShift Container Platform 4 · updated 2026-10-10 · vex