CVE-2026-43065: Linux Kernel ext4 Discard Work Drain Flaw

CVE-2026-43065 Overview

CVE-2026-43065 is a Linux kernel vulnerability in the ext4 filesystem. The flaw resides in ext4_mb_release(), which fails to drain queued discard work in specific remount scenarios. When a filesystem is mounted with the discard option and files are deleted, the kernel populates sbi->s_discard_list and queues s_discard_work. Remounting with nodiscard clears the EXT4_MOUNT_DISCARD flag without cancelling or flushing the pending work. An immediate unmount before the queued work drains can result in use of stale or freed structures.

Critical Impact
Unflushed discard work during ext4 remount and unmount sequences can lead to filesystem instability and potential kernel-level memory safety issues.

Affected Products

Linux kernel ext4 filesystem implementation (fs/ext4/mballoc.c)
Multiple stable kernel branches receiving the backported fix
Systems mounting ext4 with the discard option and supporting remount transitions

Discovery Timeline

2026-05-05 - CVE-2026-43065 published to NVD
2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43065

Vulnerability Analysis

The vulnerability affects the ext4 multi-block allocator (mballoc) discard handling logic. When ext4 is mounted with -o discard, deleting files queues asynchronous discard work onto s_discard_work via the per-superblock discard list sbi->s_discard_list. This work issues TRIM commands to the underlying block device for freed extents.

The defect occurs when an administrator remounts the filesystem with -o nodiscard. The remount path clears the EXT4_MOUNT_DISCARD flag but neither cancels nor flushes any in-flight discard work. If the filesystem is then unmounted before the worker thread completes, ext4_mb_release() proceeds without ensuring that queued work has drained. The fix updates ext4_mb_release() to always drain queued discard work regardless of the current mount flag state.

Root Cause

The root cause is a missing synchronization step between mount-flag state changes and asynchronous workqueue items. The release path conditionally drained discard work based on the current value of EXT4_MOUNT_DISCARD, but that flag can be cleared by remount while previously queued work remains pending. This is a classic race condition between mount-state mutation and deferred work execution.

Attack Vector

The issue is described in the upstream commit message as difficult to trigger deliberately outside of fuzzing scenarios. Exploitation requires local access with privileges sufficient to mount, remount, and unmount ext4 filesystems, plus the ability to delete a large number of files between operations. The maintainers note that a malicious syzkaller-style fuzzer could reach the condition. The vulnerability is a filesystem-state correctness bug in the kernel rather than a network-reachable flaw.

The vulnerability mechanism is described in prose only because no verified proof-of-concept code is published. Refer to the Kernel Git Commit 1c82f86 for the upstream patch.

Detection Methods for CVE-2026-43065

Indicators of Compromise

Kernel oops, warning, or BUG splats referencing ext4_mb_release, s_discard_work, or mb_free_blocks shortly after an ext4 unmount.
Filesystem unmount operations that follow a remount,nodiscard transition on a previously discard-mounted ext4 volume.
Unexpected kernel panics or workqueue-related stack traces during shutdown sequences on ext4 hosts.

Detection Strategies

Monitor dmesg and /var/log/kern.log for ext4 mballoc warnings and workqueue task hangs.
Audit mount and unmount syscalls to identify hosts performing discard to nodiscard remount transitions followed by rapid unmount.
Track running kernel versions across the fleet and flag systems that have not received the stable backport patches.

Monitoring Recommendations

Correlate kernel crash telemetry with ext4 mount option changes captured from configuration management or systemd journal entries.
Alert on repeated ext4 subsystem warnings on the same host, which may indicate an in-flight workqueue race.
Centralize kernel logs into a SIEM and build retention queries that surface ext4 release-path stack traces over time.

How to Mitigate CVE-2026-43065

Immediate Actions Required

Apply the upstream stable kernel patches that drain queued discard work in ext4_mb_release().
Identify all hosts running affected stable kernel branches and prioritize patching for systems that frequently remount ext4 volumes.
Avoid remounting ext4 filesystems from discard to nodiscard immediately followed by an unmount until patches are deployed.

Patch Information

The fix is distributed across multiple stable kernel branches. Reference commits include 1c82f86, 812b6a7, 9b4d9dd, 9ee29d2, b4737e2, c360e9d, and e96c235. Update to a distribution kernel that incorporates these fixes.

Workarounds

Mount ext4 filesystems with a single, stable discard policy and avoid runtime transitions between discard and nodiscard.
Issue an explicit sync and wait several seconds between any required remount,nodiscard and a subsequent unmount to allow queued work to drain.
Use periodic fstrim instead of online discard to reduce reliance on the asynchronous discard workqueue path.

bash

# Configuration example: prefer fstrim over online discard
# /etc/fstab entry without the discard option
UUID=<uuid> /data ext4 defaults,noatime 0 2

# Enable weekly fstrim via systemd timer
systemctl enable --now fstrim.timer