CVE-2026-98283 in Linux
Summary
by MITRE • 10/06/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel vulnerability identified in the KVM PPC Book3S HV subsystem represents a critical use-after-free condition within the kvmhv_emulate_tlbie_all_lpid function. This flaw arises from an improper reference counting mechanism when handling Translation Lookaside Buffer Invalidate (TLBI) operations for nested guests on PowerPC architectures. The core issue lies in the sequence of lock management and pointer retention during iteration over the nested-guest IDR. Specifically, the function iterates through a list of nested guest structures but releases the mmu_lock before invoking kvmhv_emulate_tlbie_lpid to perform actual emulation work. While holding this lock is essential for data consistency, failing to maintain a reference count on the kvm_nested_guest pointer obtained from the IDR creates a race condition window where the underlying memory can be freed by concurrent operations.
The operational impact of this vulnerability stems from a specific concurrency scenario involving nested virtualization. When a vCPU issues a single-LPID TLBI instruction with is equal to two and ric equal to two, it triggers a path through kvmhv_flush_nested which leads to kvmhv_remove_nested. This sequence results in the removal of the entry from the IDR and a decrement of its reference count via idr_remove. If this occurs while another vCPU is iterating over the same list with mmu_lock dropped, the nested guest structure may be completely released back to the kernel memory allocator through kvmhv_release_nested and kfree. The original iterating vCPU retains only a dangling pointer to this now-freed memory region. Subsequent operations such as acquiring mutex locks on gp->tlb_lock or accessing fields like shadow_pgtable, shadow_lpid, and l1_host result in reads from invalid memory addresses, potentially leading to kernel panics, data corruption, or arbitrary code execution if the freed memory has been reallocated for malicious purposes.
This vulnerability is classified under CWE-416 which denotes use after free errors, a common class of bugs where software continues to use pointers that point to memory that has already been freed. In terms of attack vectors and techniques, this aligns with ATT&CK technique T1059 Command and Scripting Interpreter if the vulnerability is leveraged for initial access or privilege escalation within the host environment. The fact that the free path is fully L1-controlled indicates that a compromised Level 1 hypervisor can directly influence the timing of memory deallocation, making this a high-severity issue in multi-tenant virtualization environments where isolation between nested guests and their parent hosts is paramount.
The resolution involves correcting the reference counting discipline to ensure pointer validity throughout the critical section. The fix requires incrementing the gp->refcnt inside the loop before dropping mmu_lock, thereby preventing the structure from being freed while it is still in use. After the per-guest work completes, the reference must be released using kvmhv_put_nested(). This approach mirrors the established get/put pattern used at every other call site that drops mmu_lock while holding a nested-guest pointer, ensuring consistency across the codebase and eliminating the race condition window. By adhering to this standard synchronization protocol, the kernel maintains memory safety even under high-concurrency scenarios involving TLBI emulation for nested guests.