CVE-2026-98433

What it actually does

On uv_page_in() failure after kvmppc_uvmem_get_page() succeeds in kvmppc_svm_page_in(), the secure page remains locked with refcount=1, the kvmppc_uvmem_bitmap entry stays set, the pvt struct leaks, and the GFN stays marked KVMPPC_GFN_UVMEM_PFN; migrate_vma_finalize() is skipped so no reclamation occurs. This permanently depletes the firmware-bounded secure memory pool and leaves the GFN unusable for the VM lifetime. The analogous error path in __kvmppc_svm_page_out() already performs the required unlock_page + put_page sequence.

Why it matters to the business

On POWER9/10 systems using Ultravisor/PEF, repeated transient errors during secure page operations (for example UV pool exhaustion) gradually exhaust the finite secure memory pool, eventually preventing new secure VMs from starting or existing ones from migrating and causing operational outages for confidential workloads.

How an attack unfolds

An attacker with the ability to trigger page-in operations into secure memory (for example by causing VM migration or page faults that invoke kvmppc_svm_page_in) can force uv_page_in() to return errors. Each such failure leaks one secure page entry without any special payload or privilege beyond normal KVM usage on an affected PEF system.

How to fix it

Apply the upstream fix that adds unlock_page(dpage) followed by put_page(dpage) in the uv_page_in() error path of kvmppc_svm_page_in() so that free_zone_device_folio() and kvmppc_uvmem_folio_free() reclaim the bitmap, pvt, and GFN state. Reboot systems after patching the kernel.

How to confirm the fix worked

Confirm the patched kernel source contains the unlock_page/put_page sequence in the uv_page_in() failure path; on running systems monitor /sys/kernel/debug/kvmppc_uvmem_bitmap usage and verify that GFN state resets correctly after transient uv_page_in() errors.

Typical attack path

1. Attacker causes or waits for a uv_page_in() call during secure page migration or fault handling.
2. uv_page_in() fails after kvmppc_uvmem_get_page() has allocated the bitmap entry and pvt struct.
3. Error path skips resource release, permanently consuming one secure memory slot.
4. Attacker repeats to exhaust the firmware-bounded pool and render secure memory unusable.

How to detect it

Inspect dmesg and kernel logs for repeated uv_page_in() error returns followed by increasing secure-memory-pool utilization; correlate with KVM migration or page-fault activity on PEF-enabled systems; examine kvmppc_uvmem_bitmap state via debugfs for leaked entries that never clear.

What your security team should do

• Prioritize patching POWER9/10 PEF hosts running KVM within the next maintenance window because each failure permanently reduces available secure memory.
• Add kernel version checks and secure-memory-pool monitoring to existing vulnerability scanning.
• Document rollback procedures in case the fix itself introduces migration regressions.