CVE-2022-48635

What it actually does

A zero-length read() on DAX-backed files via fuse triggers an infinite loop in dax_iomap_rw() because iomap_iter() returns 1 without advancing when count==0, causing a kernel WARNING and process hang.

Why it matters to the business

Local denial-of-service that can freeze processes or entire systems using virtiofs or similar DAX filesystems, reducing availability with no data loss or remote access risk.

How an attack unfolds

An attacker with local access issues a read() system call with count set to zero against a DAX-enabled file exposed through fuse/virtiofs; this reaches dax_iomap_rw() which enters a loop that never terminates because iomap_iter() keeps returning the same status.

How to fix it

Apply the upstream fix that adds an explicit count==0 check in dax_iomap_rw() before calling iomap_iter(); update to a kernel containing commit 425e833ab13373edf1dd5a0706f07100db14e3c6 or later equivalent.

How to confirm the fix worked

Confirm the patch is present by inspecting fs/dax.c for the count==0 guard; test by executing a zero-length read on a DAX file and verifying no WARNING or hang occurs.

Typical attack path

1. Obtain local execution on an affected Linux system
2. Open a DAX-backed file via fuse or virtiofs
3. Call read() with a zero byte count
4. Trigger the infinite loop and kernel warning in dax_iomap_rw()

How to detect it

Search kernel logs for the iomap_iter WARNING at fs/iomap/iter.c combined with dax_iomap_rw or fuse_dax_read_iter in the stack trace; look for repeated tail or similar processes stuck on read syscalls.

What your security team should do

• Prioritize patching systems that expose DAX filesystems via fuse or virtiofs
• Monitor for iomap_iter warnings in kernel logs
• Restrict untrusted local access until fixed kernels are deployed