CVE-2022-48943

What it actually does

The KVM async pagefault token generation in kvm_arch_setup_async_pf can produce a zero value, which kvm_arch_can_dequeue_async_page_present treats as a completed READY event, causing subsequent READY notifications to be dropped and guest tasks to remain blocked indefinitely in kvm_async_pf_task_wait_schedule.

Why it matters to the business

Virtualized workloads on affected Linux kernels may experience indefinite guest process hangs, reducing availability of services running inside VMs and requiring manual intervention or reboots to recover.

How an attack unfolds

An attacker with local access inside a guest triggers repeated async page faults while the token-generation path races such that a zero token is assigned; the hypervisor then skips delivery of the corresponding READY event, leaving the guest task permanently scheduled out.

How to fix it

Update the Linux kernel to a version containing commit 72fdfc75d4217b32363cc80def3de2cb3fef3f02 or later; for the listed Qualcomm Android trees apply the SoCVersion dated 2022-01-05 or newer.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit hash; attempt to reproduce the original stress workload and verify that kvm_async_pf_task_wait_schedule no longer results in permanent task blockage.

Typical attack path

1. Obtain local code execution inside a KVM guest
2. Exercise page-fault paths that invoke kvm_arch_setup_async_pf
3. Force the token value to zero through the identified race
4. Observe the guest task enter uninterruptible sleep in kvm_async_pf_task_wait_schedule
5. Repeat to sustain denial of service

How to detect it

Search kernel logs and guest dmesg for the hung-task signature containing kvm_async_pf_task_wait_schedule and the call trace shown in the advisory; correlate with high rates of async page faults from untrusted guest processes.

• kvm_async_pf_task_wait_schedule
• INFO: task .* blocked for more than .* seconds
• asm_exc_page_fault.*kvm_async_pf

What your security team should do

• Prioritize kernel upgrades on all KVM hosts within the next maintenance window
• Monitor for hung-task kernel messages referencing kvm_async_pf_task_wait_schedule
• Apply the fixed commit or vendor patch before the next scheduled reboot cycle