ghsa-fv86-c5hh-rvpj
Vulnerability from github
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 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] [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.
{
"affected": [],
"aliases": [
"CVE-2022-49706"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:46Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nzonefs: fix zonefs_iomap_begin() for reads\n\nIf a readahead is issued to a sequential zone file with an offset\nexactly equal to the current file size, the iomap type is set to\nIOMAP_UNWRITTEN, which will prevent an IO, but the iomap length is\ncalculated as 0. This causes a WARN_ON() in iomap_iter():\n\n[17309.548939] WARNING: CPU: 3 PID: 2137 at fs/iomap/iter.c:34 iomap_iter+0x9cf/0xe80\n[...]\n[17309.650907] RIP: 0010:iomap_iter+0x9cf/0xe80\n[...]\n[17309.754560] Call Trace:\n[17309.757078] \u003cTASK\u003e\n[17309.759240] ? lock_is_held_type+0xd8/0x130\n[17309.763531] iomap_readahead+0x1a8/0x870\n[17309.767550] ? iomap_read_folio+0x4c0/0x4c0\n[17309.771817] ? lockdep_hardirqs_on_prepare+0x400/0x400\n[17309.778848] ? lock_release+0x370/0x750\n[17309.784462] ? folio_add_lru+0x217/0x3f0\n[17309.790220] ? reacquire_held_locks+0x4e0/0x4e0\n[17309.796543] read_pages+0x17d/0xb60\n[17309.801854] ? folio_add_lru+0x238/0x3f0\n[17309.807573] ? readahead_expand+0x5f0/0x5f0\n[17309.813554] ? policy_node+0xb5/0x140\n[17309.819018] page_cache_ra_unbounded+0x27d/0x450\n[17309.825439] filemap_get_pages+0x500/0x1450\n[17309.831444] ? filemap_add_folio+0x140/0x140\n[17309.837519] ? lock_is_held_type+0xd8/0x130\n[17309.843509] filemap_read+0x28c/0x9f0\n[17309.848953] ? zonefs_file_read_iter+0x1ea/0x4d0 [zonefs]\n[17309.856162] ? trace_contention_end+0xd6/0x130\n[17309.862416] ? __mutex_lock+0x221/0x1480\n[17309.868151] ? zonefs_file_read_iter+0x166/0x4d0 [zonefs]\n[17309.875364] ? filemap_get_pages+0x1450/0x1450\n[17309.881647] ? __mutex_unlock_slowpath+0x15e/0x620\n[17309.888248] ? wait_for_completion_io_timeout+0x20/0x20\n[17309.895231] ? lock_is_held_type+0xd8/0x130\n[17309.901115] ? lock_is_held_type+0xd8/0x130\n[17309.906934] zonefs_file_read_iter+0x356/0x4d0 [zonefs]\n[17309.913750] new_sync_read+0x2d8/0x520\n[17309.919035] ? __x64_sys_lseek+0x1d0/0x1d0\n\nFurthermore, this causes iomap_readahead() to loop forever as\niomap_readahead_iter() always returns 0, making no progress.\n\nFix this by treating reads after the file size as access to holes,\nsetting the iomap type to IOMAP_HOLE, the iomap addr to IOMAP_NULL_ADDR\nand using the length argument as is for the iomap length. To simplify\nthe code with this change, zonefs_iomap_begin() is split into the read\nvariant, zonefs_read_iomap_begin() and zonefs_read_iomap_ops, and the\nwrite variant, zonefs_write_iomap_begin() and zonefs_write_iomap_ops.",
"id": "GHSA-fv86-c5hh-rvpj",
"modified": "2025-10-24T18:30:57Z",
"published": "2025-10-24T18:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49706"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/355be6131164c5bacf2e810763835aecb6e01fcb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a7f05f104347b407e865c10be2675cd833a4e48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1c1204c0d0c1dccc1310b9277fb2bd8b663d8fe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2f71b9bb398e2e573bdc2574149f42b45efe410"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.