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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-10-06T09:18:18.333Z",
  "pubdate": "2026-10-06T09:18:18.333Z",
  "executiveSummary": "This vulnerability is a use-after-free (UAF) flaw residing in the Linux kernel KVM subsystem for PowerPC Book3S HV processors, specifically within the kvmhv_emulate_tlbie_all_lpid() function.\nThe issue arises from improper reference counting when iterating through nested-guest structures while dropping the mmu_lock. This enables a race condition where a concurrent vCPU can trigger the deallocation of a nested-guest object while it is still being referenced by the iterator.\nSuccessful exploitation could lead to arbitrary code execution, system instability, or kernel memory corruption. An attacker with the ability to control L1 guest operations can trigger the removal and subsequent freeing of the target guest structure.\nThe vulnerability affects kernel configurations utilizing KVM nested virtualization on Book3S HV platforms. No specific network access is required, as the attack is orchestrated from within the L1 guest environment. Addressing this requires proper implementation of reference incrementing and decrementing cycles to ensure object persistence during concurrent operations.",
  "technicalDetails": "The root cause of this vulnerability is an unsafe reference management pattern in kvmhv_emulate_tlbie_all_lpid(). When the kernel iterates over the nested-guest IDR, it retrieves a pointer to a kvm_nested_guest structure (gp) without incrementing its reference count.\nThe function subsequently drops the mmu_lock to perform guest-specific emulation tasks. In the window between dropping the lock and completing the work, a concurrent vCPU process issuing a tlbie (is=2, ric=2) command can reach kvmhv_flush_nested(). This path proceeds through kvmhv_remove_nested(), which removes the guest from the IDR and decrements the reference count via kvmhv_release_nested(), ultimately invoking kfree(gp).\nBecause the iterator in kvmhv_emulate_tlbie_all_lpid() lacks a held reference, it is left holding a dangling pointer. When the loop attempts to acquire mutex_lock(&gp->tlb_lock) or access members such as gp->shadow_pgtable, gp->shadow_lpid, or gp->l1_host, it performs an illegal access to freed kernel memory. Since the memory for the gp structure is now potentially unallocated or reallocated for other kernel tasks, this results in a high-severity UAF condition.\nAttackers can influence this flow by triggering specific TLB invalidation sequences from the L1 guest, forcing the kernel to tear down nested guest structures during the iteration process. The impact is significant, as the exploitation of UAF in kernel space typically provides a primitive for memory corruption, potentially leading to privilege escalation or a kernel panic that induces a Denial of Service (DoS).\nThe vulnerability is inherent to the logic flow of nested virtualization support in the PPC KVM driver and does not depend on specific external network conditions, requiring only local guest-level privileges to interact with the KVM subsystem."
}