CVE-2026-43065

What it actually does

This is a local Linux kernel availability flaw in ext4 discard handling. When an ext4 filesystem is mounted with the discard option, file deletion can queue asynchronous discard work. If the filesystem is then remounted with nodiscard and quickly unmounted before the queued work drains, ext4 may release filesystem allocation state while discard work is still pending. The resolved bug ensures queued discard work is drained during ext4_mb_release(). Without the fix, a local user with sufficient privileges to mount, remount, and unmount ext4 filesystems can potentially trigger a kernel crash, panic, or other availability-impacting fault. The CVSS vector indicates local access, low attack complexity, low privileges, no user interaction, and high availability impact.

Why it matters to the business

Successful exploitation can crash affected Linux systems or make them temporarily unavailable, disrupting workloads, storage services, virtual machines, appliances, or container hosts that rely on ext4. The practical risk is lower than many kernel flaws because exploitation requires local privileges capable of manipulating mounts and a specific timing sequence, and there is no current evidence of public exploitation, KEV listing, ransomware use, or meaningful EPSS growth. Systems that allow untrusted users, containers, automation, or test workloads to perform mount operations face higher operational risk.

How an attack unfolds

An attacker first obtains local access to an affected Linux system with privileges sufficient to create or control an ext4 mount, typically requiring CAP_SYS_ADMIN or equivalent mount authority. The attacker mounts an ext4 filesystem with the discard option enabled, then deletes enough files or frees enough blocks to populate the ext4 discard queue and schedule asynchronous discard work. Before that queued work naturally completes, the attacker remounts the filesystem with nodiscard, clearing the active discard mount flag without draining the already queued work. The attacker then immediately unmounts the filesystem, racing ext4 teardown against the pending discard worker. On a vulnerable kernel, the stale queued work may run after relevant ext4 state has been released, causing a kernel oops, panic, or system hang and producing a denial of service.

How to fix it

Apply a vendor kernel update that includes the ext4 fix to always drain queued discard work in ext4_mb_release(). No exact fixed package versions were provided in the input, so use the fixed kernel version published by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable. As mitigations until patching is complete, restrict local users and containers from obtaining CAP_SYS_ADMIN or performing arbitrary mount/remount operations, avoid granting untrusted workloads access to loop devices or mount namespaces with real mount authority, limit use of ext4 mounts with the discard option where operationally feasible, and prefer controlled periodic discard via fstrim over continuous mount-time discard on systems exposed to untrusted local users.

How to confirm the fix worked

Confirm that affected systems are running a kernel build that contains the ext4 queued-discard drain fix. Validate using the distribution security advisory, package changelog, kernel source changelog, or vendor errata for this CVE. After patch deployment, verify the active kernel with uname -a or equivalent fleet inventory and ensure the system was rebooted into the fixed kernel. Review current mounts with findmnt or /proc/mounts to identify ext4 filesystems using discard. Where safe in a non-production test environment, reproduce the mount-discard, delete, remount-nodiscard, unmount sequence before and after patching to confirm the system no longer crashes or logs ext4/workqueue faults. Do not run destructive reproducer workloads on production systems.

Typical attack path

1. Gain local shell, container escape-adjacent capability, or another execution context with mount/remount/unmount privileges.
2. Prepare or select an ext4 filesystem that can be mounted by the attacker-controlled context.
3. Mount the ext4 filesystem with the discard option enabled.
4. Create and delete a large number of files, or otherwise free many blocks, to queue ext4 discard work.
5. Remount the same filesystem with nodiscard before queued discard work drains.
6. Immediately unmount the filesystem to trigger ext4 release while discard work may still be pending.
7. Observe a kernel oops, panic, hang, or forced reboot condition if the vulnerable race is hit.

How to detect it

To check for prior exploitation, review kernel logs from journald, syslog, dmesg archives, crash dump systems, and centralized log collectors for ext4-related oopses, panics, workqueue faults, or crashes near mount/remount/unmount activity. Correlate those events with auditd or EDR telemetry showing mount commands or mount syscalls that use discard followed shortly by remounts using nodiscard and then unmounts. Pay particular attention to activity by local users, CI jobs, container runtimes, fuzzing tools, privileged containers, or unexpected processes invoking mount, umount, losetup, mkfs.ext4, or file-deletion loops. Evidence is likely to be behavioral rather than a stable malware artifact: repeated ext4 mount-option changes, large bursts of deletion on a discard-enabled ext4 filesystem, and a subsequent kernel panic or reboot are the strongest indicators. If crash dumps are available, inspect stack traces for ext4 discard, mballoc, workqueue, and ext4_mb_release-related frames.

• ext4_mb_release
• s_discard_work
• EXT4_MOUNT_DISCARD
• EXT4-fs
• remount
• discard
• nodiscard
• BUG: kernel
• Oops:
• kernel panic
• workqueue
• mount -o discard
• mount -o remount,nodiscard
• umount
• syz-executor
• CAP_SYS_ADMIN
• mkfs.ext4
• losetup

What your security team should do

• Prioritize patching shared Linux hosts, virtualization nodes, CI/build workers, developer workstations, storage appliances, and container platforms where local users or workloads may have elevated mount capabilities.
• Inventory systems running ext4 with discard enabled and identify hosts where untrusted users, containers, or automation can perform mount, remount, or unmount operations.
• Remove unnecessary CAP_SYS_ADMIN, privileged container settings, loop-device access, and broad mount namespace privileges from untrusted workloads.
• Monitor kernel, syslog, journald, crash dump, and audit logs for ext4 faults, workqueue crashes, rapid discard-to-nodiscard remount sequences, and unexpected unmount activity.
• Use distribution-supported kernel live patching only if the vendor explicitly confirms coverage for this flaw; otherwise schedule a reboot into the fixed kernel.
• Because EPSS is very low, exploit maturity is listed as none, and the flaw is not in CISA KEV, handle this as a medium-priority local DoS issue unless the environment exposes mount privileges to untrusted users.