CVE-2026-43065
Description
In the Linux kernel, the following vulnerability has been resolved:
ext4: always drain queued discard work in ext4_mb_release()
While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]:
> If the filesystem is initially mounted with the discard option, > deleting files will populate sbi->s_discard_list and queue > s_discard_work. If it is then remounted with nodiscard, the > EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is > neither cancelled nor flushed.
[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev
The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing.
In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own.
Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Pending ext4 discard work is not drained on remount with nodiscard, potentially causing data corruption on unmount.
Vulnerability
In the Linux kernel's ext4 filesystem, when the filesystem is remounted from "discard" to "nodiscard" mode, the pending discard work (s_discard_work) queued during file deletions is neither cancelled nor flushed. This occurs because the EXT4_MOUNT_DISCARD flag is cleared, but the work remains queued and may execute after the remount, potentially freeing blocks that are still in use.
Exploitation
Exploiting this vulnerability requires a specific sequence: mount the filesystem with -o discard, delete a large number of files to populate the discard list, remount with -o nodiscard, and then immediately unmount before the queued work drains. While this is difficult to trigger accidentally, a malicious local user or a fuzzer like syzkaller could deliberately orchestrate this scenario to cause filesystem corruption.
Impact
If successfully triggered, the pending discard operations could free blocks that are still referenced by inodes, leading to data corruption and potential data loss. The issue is considered a real bug, though it is hard to exploit in real-world usage without intent.
Mitigation
The fix ensures that all queued discard work is drained in ext4_mb_release() regardless of the discard mount flag. Patches have been applied to the stable kernel trees as commits [1], [2], [3], and [4].
AI Insight generated on May 18, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
7- git.kernel.org/stable/c/1c82f863f090ab899085bdfade073313384b514bnvd
- git.kernel.org/stable/c/812b6a7cd3e7f3a3e8a24db85bc6313c26cb1098nvd
- git.kernel.org/stable/c/9b4d9dda6a71ad3425c8109d27c4c6bfb9da97b8nvd
- git.kernel.org/stable/c/9ee29d20aab228adfb02ca93f87fb53c56c2f3afnvd
- git.kernel.org/stable/c/b4737e26d4688b8aea88ad6ea4dbfeb6e78b0327nvd
- git.kernel.org/stable/c/c360e9d0def4f4ae03254a67c683103908555b75nvd
- git.kernel.org/stable/c/e96c2354b170aaa53300c8e8fd59e41b133160f7nvd
News mentions
0No linked articles in our index yet.