CVE-2026-31465: Linux Kernel Writeback DoS Vulnerability

CVE-2026-31465 Overview

A vulnerability has been resolved in the Linux kernel's writeback subsystem that could cause system hangs during sync operations on filesystems without data integrity guarantees, particularly affecting FUSE-based filesystems. The issue occurs when sync operations block waiting for flusher threads to complete writeback on filesystems like fuse-overlayfs, which cannot guarantee data persistence.

Critical Impact

This vulnerability can cause suspend-to-RAM hangs and system freezes when sync operations block indefinitely on FUSE filesystems, particularly when the FUSE daemon is frozen or unresponsive.

Affected Products

• Linux kernel (versions prior to patch)
• Systems using FUSE-based filesystems (e.g., fuse-overlayfs)
• Systems utilizing suspend-to-RAM with FUSE mounts

Discovery Timeline

• 2026-04-22 - CVE CVE-2026-31465 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-31465

Vulnerability Analysis

This vulnerability exists in the Linux kernel's writeback mechanism, specifically affecting filesystems that cannot provide data integrity guarantees during sync operations. The core issue stems from the previous implementation where the per-inode AS_NO_DATA_INTEGRITY mapping flag was used to handle filesystems without data persistence guarantees. This approach was fundamentally flawed because data integrity is a filesystem-wide property, not a per-inode characteristic.

When a sync operation is triggered (such as during suspend-to-RAM), the kernel's sync_inodes_sb() function would wait for flusher threads to complete writeback operations. For FUSE filesystems, this waiting behavior becomes problematic in several scenarios: when systemd freezes user session cgroups before invoking kernel suspend (which freezes the FUSE daemon), the kernel's ->write_node() callback issues a synchronous setattr request that cannot be processed since the daemon is frozen.

Additionally, if a FUSE daemon is buggy and cannot properly complete writeback, initiating writeback on a dirty folio already under writeback leads to writeback_get_folio() calling folio_prepare_writeback(), which unconditionally waits for writeback to finish, causing a deadlock condition.

Root Cause

The root cause is the inappropriate placement of the data integrity flag at the inode level rather than the superblock level. The previous implementation using the AS_NO_DATA_INTEGRITY mapping flag (added in commit f9a49aa302a0) caused the kernel to still wait on flusher threads to finish initiating writeback, even though it skipped waiting on writeback completion. This waiting on flusher threads is unnecessary for filesystems without data integrity guarantees and creates the conditions for the observed hangs.

Attack Vector

This is a local denial of service condition that can be triggered under specific circumstances:

1. A system with FUSE-based filesystems mounted (such as fuse-overlayfs)
2. Dirty inodes present on the FUSE filesystem
3. A sync operation triggered (either explicitly or via suspend-to-RAM)
4. The FUSE daemon being frozen, unresponsive, or buggy

The vulnerability manifests in the wb_wait_for_completion() function within the PM filesystem sync workqueue, as shown in the call trace from the kernel report. The pm_fs_sync_work_fn function triggers sync_inodes_sb() which waits indefinitely for the frozen FUSE daemon to respond.

Detection Methods for CVE-2026-31465

Indicators of Compromise

• System hangs during suspend-to-RAM operations with FUSE filesystems mounted
• Kernel tasks stuck in wb_wait_for_completion() visible in stack traces
• Uninterruptible processes related to pm_fs_sync workqueue operations
• High wait times in the writeback subsystem when FUSE mounts are active

Detection Strategies

• Monitor for processes stuck in uninterruptible sleep (D state) with sync_inodes_sb in their stack trace
• Check dmesg or kernel logs for hung task warnings related to pm_fs_sync_work_fn or writeback operations
• Use sysrq-t during hangs to capture stack traces and identify writeback-related deadlocks
• Audit systems for FUSE filesystem mounts that may be affected, particularly fuse-overlayfs configurations

Monitoring Recommendations

• Implement alerting on kernel hung task warnings, especially those mentioning writeback or sync operations
• Monitor suspend/resume cycles for failures or extended duration on systems with FUSE mounts
• Track FUSE daemon health and responsiveness on affected systems
• Review systemd unit ordering to ensure FUSE daemons are not frozen before kernel suspend sync

How to Mitigate CVE-2026-31465

Immediate Actions Required

• Apply the kernel patches that introduce the SB_I_NO_DATA_INTEGRITY superblock flag
• Ensure FUSE daemons are properly ordered in systemd to remain active during suspend operations
• Consider unmounting FUSE filesystems before suspend if patching is not immediately possible
• Review and update to the latest stable kernel version containing the fix

Patch Information

The fix introduces a new SB_I_NO_DATA_INTEGRITY superblock flag for filesystems that cannot guarantee data persistence on sync. For superblocks with this flag set, sync operations kick off writeback of dirty inodes but do not wait for the flusher threads to complete. This restores FUSE to its prior behavior before tmp folios were removed, where sync was essentially a no-op for these filesystem types.

Patches are available from the following kernel commits:

• Kernel Git Commit 5c24a13
• Kernel Git Commit 76f9377
• Kernel Git Commit 83800f8

Workarounds

• Configure systemd to avoid freezing FUSE daemon cgroups before kernel suspend by adjusting FreezerScope settings
• Unmount FUSE filesystems before initiating suspend-to-RAM operations
• If possible, avoid using suspend-to-RAM on systems heavily dependent on FUSE filesystems until patched
• Consider using alternative suspend modes (e.g., hibernate) that may not trigger the same sync behavior