CVE-2026-89646 in Linux
Résumé
par VulDB • 12/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ceph : correction de la fuite de référence d'inode lors de l'annulation du writeback au moment du démontage (umount)
La fonction `ceph_dirty_folio()` acquiert une revendication sur le buffer d'écriture (`wrbuffer`) pour chaque folio nouvellement marqué comme sale ; elle incrémente `i_wrbuffer_ref` (en prenant un `ihold()` lors de la transition 0->1) et attache le contexte de snapshot à `folio->private`. Cette revendication n'est libérée que par `ceph_put_wrbuffer_cap_refs()`, qui, pour une écriture soumise, s'exécute depuis `writepages_finish()`.
Dans `ceph_submit_write()`, si l'appel à `ceph_inc_osd_stopping_blocker()` échoue — ce qui se produit lors du démontage (`umount`) — la requête est annulée avant sa soumission : les folios déjà collectés sont simplement marqués comme sales et déverrouillés, de sorte que `writepages_finish()` ne s'exécute jamais et que la revendication fuit.
`redirty_page_for_writepage()` -> `folio_redirty_for_writepage()` -> `filemap_dirty_folio()` définit directement l'indicateur PG_dirty sans passer par `->dirty_folio`, de sorte que `ceph_dirty_folio()` n'est pas rappelée pour rééquilibrer la situation. Étant donné que chaque écriture ultérieure échoue également au niveau du blocage osd_stopping, `i_wrbuffer_ref` ne revient jamais à 0, le `ihold()` n'est jamais libéré et l'inode ne peut pas être évicté :
``` VFS: Busy inodes after unmount of ceph kernel BUG at fs/super.c:650! ```
Libérer la revendication orpheline dans le chemin d'annulation avant de marquer à nouveau comme sale, via `ceph_undo_wrbuffer_claim()` : détacher le contexte de snapshot, libérer la référence au buffer d'écriture (permettant à `i_wrbuffer_ref` d'atteindre 0 et en appelant `iput()` sur l'inode), et libérer la référence au contexte de snapshot — c'est-à-dire effectuer ce que `writepages_finish()` aurait fait pour ces folios jamais soumis.
Seules les entrées `locked_pages` sont annulées ; les folios encore présents dans le `fbatch` n'ont pas été effacés (marqués comme non sales) par cet appel (`folio_clear_dirty_for_io()` est le point de transfert de propriété, et un déplacement réussi nullifie l'emplacement du fbatch), ils ne portent donc aucune revendication dont cet appel a la charge.
If you want to get best quality of vulnerability data, you may have to visit VulDB.