Bug 2535141 (CVE-2026-89836)

Summary:	CVE-2026-89836 kernel: f2fs: fix folio_nr_pages() race after put in large folio invalidate
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	akhatavk, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the Linux kernel's f2fs (Flash-Friendly File System) component. A race condition occurs during the invalidation of large folios (memory pages), where the system incorrectly determines the size of the memory range. This can happen if another process concurrently modifies or frees the memory folio. This vulnerability could lead to a system livelock, rendering the system unresponsive, and potentially cause data corruption due to stale memory entries.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-09-16 10:58:16 UTC

In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix folio_nr_pages() race after put in large folio invalidate

Our v6.18 based Android system is continuely suffering livelock and bad
page stat as shown in[1] which related to broken xarray slot status. By
investigating big folio operations within f2fs, we find below races and
fix it by get the nr_pages before drop the refcount and folio_lock.

f2fs_get_read_data_folio() calls f2fs_folio_put() before
folio_nr_pages() when invalidating a large folio from the page cache.
That unlocks the folio and drops the caller reference, leaving a window
where a concurrent truncate or folio split can shrink the compound folio
or free it before the invalidate range is computed. An undersized range
then leaves split sub-folios in mapping->i_pages, which can later
interact badly with truncate and reclaim (stale xarray entries and bad
page state when folio->mapping no longer matches the mapping being
truncated).

[1]
PID: 2594     TASK: ffffff8169b81580  CPU: 7    COMMAND: "Thread-3"
 #0 [ffffffc08ef2b8a0] xas_load at ffffffe52d1f42a4
 #1 [ffffffc08ef2b900] find_get_entries at ffffffe52c185798
 #2 [ffffffc08ef2bb60] truncate_inode_pages_range at ffffffe52c19e83c
 #3 [ffffffc08ef2bbc0] truncate_inode_pages_final at ffffffe52c19ec2c
 #4 [ffffffc08ef2bc20] f2fs_evict_inode at ffffffe52c4c8400
 #5 [ffffffc08ef2bcc0] evict at ffffffe52c2de9f4
 #6 [ffffffc08ef2bd00] iput at ffffffe52c2db1b4
 #7 [ffffffc08ef2bd30] dentry_unlink_inode at ffffffe52c2d7204
 #8 [ffffffc08ef2bd50] __dentry_kill at ffffffe52c2d3dcc
 #9 [ffffffc08ef2bd80] dput at ffffffe52c2d3c3c
 #10 [ffffffc08ef2bda0] __fput at ffffffe52c2b0a7c
 #11 [ffffffc08ef2bde0] ____fput at ffffffe52c2b1034
 #12 [ffffffc08ef2bdf0] task_work_run at ffffffe52beea200
 #13 [ffffffc08ef2be20] exit_to_user_mode_loop at ffffffe52bfbc17c
 #14 [ffffffc08ef2be80] el0_svc at ffffffe52d1f8e54
 #15 [ffffffc08ef2beb0] el0t_64_sync_handler at ffffffe52d1f8d10

Comment 1 Mauro Matteo Cascella 2026-09-21 18:17:59 UTC

Upstream advisory:
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-89836.mbox