CVE-2022-49706
Published: 26 February 2025
Summary
CVE-2022-49706 is a high-severity Out-of-bounds Read (CWE-125) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.1 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Application or System Exploitation (T1499.004); ranked at the 2.8th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified are NIST 800-53 CM-7 (Least Functionality) and SI-2 (Flaw Remediation).
Deeper analysis
CVE-2022-49706 is a vulnerability in the Linux kernel's zonefs filesystem, specifically in the zonefs_iomap_begin() function handling reads. When a readahead operation targets a sequential zone file at an offset exactly equal to the current file size, the iomap type is incorrectly set to IOMAP_UNWRITTEN with a length of zero. This triggers a WARN_ON() assertion in iomap_iter() at fs/iomap/iter.c:34 and causes iomap_readahead() to enter an infinite loop, as iomap_readahead_iter() repeatedly returns zero without progress.
A local attacker with low privileges (PR:L) can exploit this vulnerability without user interaction by issuing a read or readahead on a zonefs sequential zone file at its end-of-file offset. Successful exploitation results in a kernel warning, potential information disclosure via stack traces (C:H), and a denial-of-service condition through process hang due to the infinite loop (A:H), with no integrity impact (I:N). The CVSS v3.1 base score is 7.1 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H), linked to CWE-125 (Out-of-bounds Read).
Mitigation requires applying upstream kernel patches, such as those in the referenced stable commits: 355be6131164c5bacf2e810763835aecb6e01fcb, 3a7f05f104347b407e865c10be2675cd833a4e48, c1c1204c0d0c1dccc1310b9277fb2bd8b663d8fe, and c2f71b9bb398e2e573bdc2574149f42b45efe410. These fixes treat post-file-size reads as holes by setting the iomap type to IOMAP_HOLE, addr to IOMAP_NULL_ADDR, and using the provided length; they also refactor zonefs_iomap_begin() into separate read (zonefs_read_iomap_begin() and zonefs_read_iomap_ops) and write variants.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2022-54529
Vulnerability details
In the Linux kernel, the following vulnerability has been resolved: zonefs: fix zonefs_iomap_begin() for reads If a readahead is issued to a sequential zone file with an offset exactly equal to the current file size, the iomap type is set…
more
to IOMAP_UNWRITTEN, which will prevent an IO, but the iomap length is calculated as 0. This causes a WARN_ON() in iomap_iter(): [17309.548939] WARNING: CPU: 3 PID: 2137 at fs/iomap/iter.c:34 iomap_iter+0x9cf/0xe80 [...] [17309.650907] RIP: 0010:iomap_iter+0x9cf/0xe80 [...] [17309.754560] Call Trace: [17309.757078] <TASK> [17309.759240] ? lock_is_held_type+0xd8/0x130 [17309.763531] iomap_readahead+0x1a8/0x870 [17309.767550] ? iomap_read_folio+0x4c0/0x4c0 [17309.771817] ? lockdep_hardirqs_on_prepare+0x400/0x400 [17309.778848] ? lock_release+0x370/0x750 [17309.784462] ? folio_add_lru+0x217/0x3f0 [17309.790220] ? reacquire_held_locks+0x4e0/0x4e0 [17309.796543] read_pages+0x17d/0xb60 [17309.801854] ? folio_add_lru+0x238/0x3f0 [17309.807573] ? readahead_expand+0x5f0/0x5f0 [17309.813554] ? policy_node+0xb5/0x140 [17309.819018] page_cache_ra_unbounded+0x27d/0x450 [17309.825439] filemap_get_pages+0x500/0x1450 [17309.831444] ? filemap_add_folio+0x140/0x140 [17309.837519] ? lock_is_held_type+0xd8/0x130 [17309.843509] filemap_read+0x28c/0x9f0 [17309.848953] ? zonefs_file_read_iter+0x1ea/0x4d0 [zonefs] [17309.856162] ? trace_contention_end+0xd6/0x130 [17309.862416] ? __mutex_lock+0x221/0x1480 [17309.868151] ? zonefs_file_read_iter+0x166/0x4d0 [zonefs] [17309.875364] ? filemap_get_pages+0x1450/0x1450 [17309.881647] ? __mutex_unlock_slowpath+0x15e/0x620 [17309.888248] ? wait_for_completion_io_timeout+0x20/0x20 [17309.895231] ? lock_is_held_type+0xd8/0x130 [17309.901115] ? lock_is_held_type+0xd8/0x130 [17309.906934] zonefs_file_read_iter+0x356/0x4d0 [zonefs] [17309.913750] new_sync_read+0x2d8/0x520 [17309.919035] ? __x64_sys_lseek+0x1d0/0x1d0 Furthermore, this causes iomap_readahead() to loop forever as iomap_readahead_iter() always returns 0, making no progress. Fix this by treating reads after the file size as access to holes, setting the iomap type to IOMAP_HOLE, the iomap addr to IOMAP_NULL_ADDR and using the length argument as is for the iomap length. To simplify the code with this change, zonefs_iomap_begin() is split into the read variant, zonefs_read_iomap_begin() and zonefs_read_iomap_ops, and the write variant, zonefs_write_iomap_begin() and zonefs_write_iomap_ops.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Local low-priv read on zonefs triggers kernel infinite loop (DoS) and stack-trace info leak via direct exploitation of the out-of-bounds iomap condition.
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Directly remediates the zonefs_iomap_begin() flaw by requiring timely application of kernel patches that fix post-EOF read handling as IOMAP_HOLE.
Restricts enabling unnecessary filesystems like zonefs, eliminating the vulnerable sequential zone file readahead path for local attackers.
Mandates proper error handling for iomap conditions to avoid WARN_ON stack trace disclosures and infinite loops in iomap_readahead.