CVE-2025-37779: lib/iov_iter: fix to increase non slab folio refcount
In the Linux kernel, the following vulnerability has been resolved:
lib/iov_iter: fix to increase non slab folio refcount
When testing EROFS file-backed mount over v9fs on qemu, I encountered a
folio UAF issue. The page sanity check reports the following call trace.
The root cause is that pages in bvec are coalesced across a folio bounary.
The refcount of all non-slab folios should be increased to ensure
p9_releas_pages can put them correctly.
BUG: Bad page state in process md5sum pfn:18300
page: refcount:0 mapcount:0 mapping:00000000d5ad8e4e index:0x60 pfn:0x18300
head: order:0 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
aops:z_erofs_aops ino:30b0f dentry name(?):"GoogleExtServicesCn.apk"
flags: 0x100000000000041(locked|head|node=0|zone=1)
raw: 0100000000000041 dead000000000100 dead000000000122 ffff888014b13bd0
raw: 0000000000000060 0000000000000020 00000000ffffffff 0000000000000000
head: 0100000000000041 dead000000000100 dead000000000122 ffff888014b13bd0
head: 0000000000000060 0000000000000020 00000000ffffffff 0000000000000000
head: 0100000000000000 0000000000000000 ffffffffffffffff 0000000000000000
head: 0000000000000010 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
Call Trace:
dump_stack_lvl+0x53/0x70
bad_page+0xd4/0x220
__free_pages_ok+0x76d/0xf30
__folio_put+0x230/0x320
p9_release_pages+0x179/0x1f0
p9_virtio_zc_request+0xa2a/0x1230
p9_client_zc_rpc.constprop.0+0x247/0x700
p9_client_read_once+0x34d/0x810
p9_client_read+0xf3/0x150
v9fs_issue_read+0x111/0x360
netfs_unbuffered_read_iter_locked+0x927/0x1390
netfs_unbuffered_read_iter+0xa2/0xe0
vfs_iocb_iter_read+0x2c7/0x460
erofs_fileio_rq_submit+0x46b/0x5b0
z_erofs_runqueue+0x1203/0x21e0
z_erofs_readahead+0x579/0x8b0
read_pages+0x19f/0xa70
page_cache_ra_order+0x4ad/0xb80
filemap_readahead.isra.0+0xe7/0x150
filemap_get_pages+0x7aa/0x1890
filemap_read+0x320/0xc80
vfs_read+0x6c6/0xa30
ksys_read+0xf9/0x1c0
do_syscall_64+0x9e/0x1a0
entry_SYSCALL_64_after_hwframe+0x71/0x79
Security readout for executives and security teams
Plain-English summary
A Linux kernel reference-counting flaw can free memory while it is still in use during certain file reads. The reported failure occurred with an EROFS file-backed mount over v9fs in QEMU. Successful triggering could crash the system or corrupt sensitive kernel memory; the supplied CVSS assessment also allows confidentiality and integrity impact.
Executive priority
Treat this as a high-priority kernel update for exposed virtualization and file-serving systems. Schedule remediation promptly, while prioritizing hosts that permit untrusted local users or use v9fs with EROFS. Emergency incident response is not justified solely by the supplied evidence because active exploitation has not been established.
Technical view
Pages in a bvec may be coalesced across a folio boundary without incrementing every non-slab folio reference count. When p9_release_pages later drops those references, a folio can be released prematurely, causing a use-after-free and bad-page state. The kernel fix increases the required folio reference counts.
Likely exposure
Prioritize systems using the listed affected Linux 6.14 through 6.15 versions, especially virtualization or file-serving workloads combining v9fs with EROFS-backed reads. The bundle identifies a specific observed configuration, but does not establish that every listed kernel installation is practically triggerable.
Exploitation context
The supplied CVSS 3.1 vector is 7.8 and requires local access with low privileges, low complexity, and no user interaction. CISA KEV status is false, and the sources provide no evidence of active exploitation or a public exploit. Practical reliability and impact beyond the reported use-after-free remain unclear.
Researcher notes
The observed fault path runs from EROFS readahead through v9fs zero-copy reads to p9_release_pages. The root issue is incomplete reference acquisition when bvec entries cross folio boundaries. The bundle names two stable commits but does not provide complete distribution package mappings, exploitability analysis, or evidence that the reported configuration covers every possible trigger.
Mitigation direction
Update to a vendor-supported kernel containing the referenced stable fix commits.
Check distribution advisories to identify the exact fixed package for each operating system.
Where updating is delayed, restrict untrusted local access to systems using the affected storage configuration.
Consider avoiding the implicated EROFS-over-v9fs workflow until vendor remediation is applied.
Validation and detection
Inventory running kernel versions and identify systems within the supplied affected 6.14-to-6.15 range.
Identify hosts using v9fs, particularly EROFS file-backed mounts in virtualized environments.
Confirm installed kernel packages include the applicable referenced stable fix.
Review kernel logs for bad-page reports, folio warnings, or traces involving p9_release_pages.
Reboot after updating and verify the remediated kernel is running.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-37779 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.