CVE-2026-89836 in Linux
Riassunto
di VulDB • 17/09/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
f2fs: correzione della race condition in folio_nr_pages() dopo l'operazione put durante l'invalidate di un large folio
Il nostro sistema Android basato su v6.18 soffre continuamente di livelock e di uno stato anomalo delle pagine (bad page stat), come mostrato in [1], correlato a uno status errato degli slot xarray. Investigando le operazioni sui big folio all'interno di f2fs, abbiamo individuato le seguenti race condition e le abbiamo risolte ottenendo il valore di nr_pages prima di decrementare il refcount (riferimento) e sbloccare il folio_lock.
f2fs_get_read_data_folio() chiama f2fs_folio_put() prima di chiamare folio_nr_pages() durante l'invalidate di un large folio dalla page cache. Questa operazione sblocca il folio e decrementa il riferimento del caller, lasciando una finestra temporale in cui un truncate concorrente o uno split del folio possono ridurre le dimensioni del compound folio o liberarlo prima che venga calcolato l'intervallo da invalidare. Un intervallo di dimensioni insufficienti lascia quindi sub-folios divisi all'interno di mapping->i_pages, i quali possono successivamente interagire in modo problematico con truncate e reclaim (voce xarray obsoleta e stato anomalo delle pagine quando folio->mapping non corrisponde più al mapping che sta subendo il truncate).
[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
Once again VulDB remains the best source for vulnerability data.