Skip to main content

Linux Kernel ext4 CVE-2026-43065

| EUVDEUVD-2026-27363 MEDIUM
2026-05-05 Linux GHSA-86wv-8x6p-4rhg
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

4
Analysis Generated
May 29, 2026 - 20:35 vuln.today
CVSS changed
May 29, 2026 - 18:22 NVD
5.5 (MEDIUM)
Patch available
May 05, 2026 - 17:31 EUVD
CVE Published
May 05, 2026 - 15:23 nvd
MEDIUM 5.5

DescriptionCVE.org

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.

AnalysisAI

Availability impact in the Linux kernel's ext4 filesystem subsystem arises from improperly managed discard workqueue lifecycle during remount and unmount operations. When a filesystem mounted with -o discard is remounted with -o nodiscard and then immediately unmounted, pending s_discard_work workqueue items are neither cancelled nor flushed before superblock teardown, potentially causing the work callback to reference freed memory and crash the kernel. Patch commits are confirmed across multiple stable branches; EPSS is 0.02% (7th percentile) and no KEV listing or public exploit exists, indicating negligible real-world exploitation risk outside of automated fuzzer (syzkaller) scenarios.

Technical ContextAI

The vulnerability resides in ext4_mb_release() within the ext4 multiblock allocator (fs/ext4/mballoc.c). The ext4 filesystem supports TRIM/discard operations for flash storage, using sbi->s_discard_list to batch pending discard requests and s_discard_work (a kernel workqueue item) to submit them asynchronously. When the EXT4_MOUNT_DISCARD mount flag is cleared via remount (-o remount,nodiscard), the code path that clears the flag does not call cancel_work_sync() or flush_work() on s_discard_work. Consequently, inflight or queued work items can execute against ext4 superblock structures (sbi) that are freed during the subsequent unmount path. While CWE is not formally assigned, the root cause maps conceptually to improper synchronization of kernel work queues (analogous to CWE-667 Improper Locking or CWE-416 Use After Free depending on exact memory lifetime). The CPE identifier cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:* covers all affected kernel versions introduced after commit 55cdd0af2bc5ffc92a2deb745627755aecd5db33.

RemediationAI

Apply the appropriate patched Linux kernel release for your stable branch: 5.15.203, 6.1.168, 6.6.131, 6.12.80, 6.18.21, 6.19.11, or 7.0. Individual stable-tree fix commits are available at https://git.kernel.org/stable/c/e96c2354b170aaa53300c8e8fd59e41b133160f7, https://git.kernel.org/stable/c/c360e9d0def4f4ae03254a67c683103908555b75, https://git.kernel.org/stable/c/1c82f863f090ab899085bdfade073313384b514b, https://git.kernel.org/stable/c/9b4d9dda6a71ad3425c8109d27c4c6bfb9da97b8, https://git.kernel.org/stable/c/812b6a7cd3e7f3a3e8a24db85bc6313c26cb1098, https://git.kernel.org/stable/c/b4737e26d4688b8aea88ad6ea4dbfeb6e78b0327, and https://git.kernel.org/stable/c/9ee29d20aab228adfb02ca93f87fb53c56c2f3af. As an operational workaround, avoid the specific sequence of mounting ext4 with -o discard, performing mass file deletions, then immediately remounting with -o nodiscard followed by rapid unmount; in practice, allowing a brief settling period before unmount would allow background work to drain naturally. Systems that do not use the ext4 discard mount option are not affected and require no action.

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-43065 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy