Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

CVE-2026-31465

Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
22/04/2026
Última modificación:
23/04/2026

Descripción

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> writeback: don&amp;#39;t block sync for filesystems with no data integrity guarantees<br /> <br /> Add a SB_I_NO_DATA_INTEGRITY superblock flag for filesystems that cannot<br /> guarantee data persistence on sync (eg fuse). For superblocks with this<br /> flag set, sync kicks off writeback of dirty inodes but does not wait<br /> for the flusher threads to complete the writeback.<br /> <br /> This replaces the per-inode AS_NO_DATA_INTEGRITY mapping flag added in<br /> commit f9a49aa302a0 ("fs/writeback: skip AS_NO_DATA_INTEGRITY mappings<br /> in wait_sb_inodes()"). The flag belongs at the superblock level because<br /> data integrity is a filesystem-wide property, not a per-inode one.<br /> Having this flag at the superblock level also allows us to skip having<br /> to iterate every dirty inode in wait_sb_inodes() only to skip each inode<br /> individually.<br /> <br /> Prior to this commit, mappings with no data integrity guarantees skipped<br /> waiting on writeback completion but still waited on the flusher threads<br /> to finish initiating the writeback. Waiting on the flusher threads is<br /> unnecessary. This commit kicks off writeback but does not wait on the<br /> flusher threads. This change properly addresses a recent report [1] for<br /> a suspend-to-RAM hang seen on fuse-overlayfs that was caused by waiting<br /> on the flusher threads to finish:<br /> <br /> Workqueue: pm_fs_sync pm_fs_sync_work_fn<br /> Call Trace:<br /> <br /> __schedule+0x457/0x1720<br /> schedule+0x27/0xd0<br /> wb_wait_for_completion+0x97/0xe0<br /> sync_inodes_sb+0xf8/0x2e0<br /> __iterate_supers+0xdc/0x160<br /> ksys_sync+0x43/0xb0<br /> pm_fs_sync_work_fn+0x17/0xa0<br /> process_one_work+0x193/0x350<br /> worker_thread+0x1a1/0x310<br /> kthread+0xfc/0x240<br /> ret_from_fork+0x243/0x280<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> On fuse this is problematic because there are paths that may cause the<br /> flusher thread to block (eg if systemd freezes the user session cgroups<br /> first, which freezes the fuse daemon, before invoking the kernel<br /> suspend. The kernel suspend triggers -&gt;write_node() which on fuse issues<br /> a synchronous setattr request, which cannot be processed since the<br /> daemon is frozen. Or if the daemon is buggy and cannot properly complete<br /> writeback, initiating writeback on a dirty folio already under writeback<br /> leads to writeback_get_folio() -&gt; folio_prepare_writeback() -&gt;<br /> unconditional wait on writeback to finish, which will cause a hang).<br /> This commit restores fuse to its prior behavior before tmp folios were<br /> removed, where sync was essentially a no-op.<br /> <br /> [1] https://lore.kernel.org/linux-fsdevel/CAJnrk1a-asuvfrbKXbEwwDSctvemF+6zfhdnuzO65Pt8HsFSRw@mail.gmail.com/T/#m632c4648e9cafc4239299887109ebd880ac6c5c1

Impacto