CVE-2022-48862

What it actually does

Improper input validation in vhost_iotlb_add_range_ctx allows userspace to insert an IOTLB entry with size 0 spanning [0, ULONG_MAX], causing iotlb_access_ok to loop indefinitely on subsequent packet operations.

Why it matters to the business

Local denial-of-service condition that can hang vhost worker threads, disrupting virtual networking or device functionality on affected Linux systems until the system is restarted or the thread is killed.

How an attack unfolds

A local attacker with access to vhost character devices sends an IOTLB mapping message containing iova=size=uaddr=0; the kernel stores a malformed entry; any later send operation invokes iotlb_access_ok which never terminates, hanging the vhost_worker kthread.

How to fix it

Upgrade the Linux kernel to a version containing commit f8d88e86e90ea1002226d7ac2430152bfea003d1, which adds an -EINVAL check for zero-size ranges and splits the [0, ULONG_MAX] case into two entries.

How to confirm the fix worked

Confirm the running kernel contains commit f8d88e86e90ea1002226d7ac2430152bfea003d1 or later; recompile with the patch and verify that zero-size IOTLB messages now return -EINVAL without hanging threads.

Typical attack path

1. Obtain local access and open a vhost character device
2. Issue vhost_process_iotlb_msg with a zero-size range
3. Trigger a vhost packet send path (vq_meta_prefetch)
4. Observe indefinite loop in iotlb_access_ok and hung vhost_worker thread

How to detect it

Review kernel logs for the exact call trace containing iotlb_access_ok, vq_meta_prefetch, vhost_transport_do_send_pkt and vhost_worker; correlate with processes opening vhost character devices shortly before the hang.

• iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340
• vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372
• vhost_process_iotlb_msg

What your security team should do

• Apply the referenced kernel commit or distribution update as soon as possible on all systems exposing vhost interfaces
• Restrict unprivileged access to /dev/vhost* devices via permissions or SELinux policies
• Monitor for vhost_worker threads in uninterruptible sleep states