CVE-2026-43066

What it actually does

The flaw is a local denial-of-service issue in the Linux kernel ext4 filesystem fast-commit replay path. When ext4_fc_replay_inode() encounters certain errors, it fails to release a referenced buffer_head for the inode location. Repeatedly triggering those error paths can leak kernel memory or filesystem buffer references, potentially leading to memory pressure, mount/recovery failures, or system instability. The issue does not directly provide data theft, privilege escalation, or file modification; the primary impact is availability.

Why it matters to the business

A successful attack can make affected Linux systems unstable or unavailable, especially systems that allow local users, containers, removable media, disk images, or automated mount workflows to exercise ext4 filesystem recovery paths. Because the Linux kernel is widely deployed, exposure may exist across servers, workstations, appliances, and embedded systems, but urgency is moderated by the local-access requirement, low EPSS score, lack of known exploitation, and absence from CISA KEV. Organizations should still remediate through normal kernel patch cycles, prioritizing shared multi-user systems and platforms that process untrusted storage media or filesystem images.

How an attack unfolds

An attacker first needs local execution or another way to cause the target kernel to mount or recover an ext4 filesystem that reaches the affected fast-commit replay code. The attacker prepares or manipulates an ext4 filesystem state so that ext4_fc_replay_inode() obtains an inode buffer reference and then hits one of the vulnerable error paths, such as failures in dirty metadata handling, dirty buffer synchronization, inode marking, or inode lookup. Because the vulnerable kernel does not release the referenced buffer before returning, each failed replay can leak kernel resources. By repeating the trigger through mount, recovery, loop-device, removable-media, or similar workflows, the attacker may exhaust resources and cause degraded performance, mount failures, kernel memory pressure, or a denial of service.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the ext4 fix for ext4_fc_replay_inode() releasing iloc.bh on all error paths and propagating errors correctly. No universal fixed package version was provided, so use vendor advisories, kernel changelogs, or source verification to confirm inclusion of the patch titled "ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths." After installing the updated kernel, reboot into it and remove or restrict use of vulnerable kernels. As interim mitigation, restrict untrusted users from mounting filesystems or attaching loop devices, limit access to removable media and untrusted disk images, review use of user namespaces and mount helpers, and avoid automated mounting of untrusted ext4 images on vulnerable systems.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not merely that an updated package is installed. Validate with kernel package metadata, vendor advisory references, or source/changelog evidence showing the ext4_fc_replay_inode() fix is present. On source-based systems, verify the function has an error path that releases iloc.bh, such as an out_brelse label or equivalent brelse() before returning. After reboot, check uname and package manager output to ensure the fixed kernel is active. Operationally, monitor dmesg/journal logs during ext4 mount and recovery operations and confirm there are no recurring ext4 fast-commit replay errors, mount failures, or memory pressure symptoms associated with ext4 recovery.

Typical attack path

1. Gain local code execution, access to a mount-capable workflow, or the ability to supply a filesystem image/removable disk to the affected system.
2. Create or manipulate an ext4 filesystem image that uses fast-commit replay conditions and can trigger an error path in ext4_fc_replay_inode().
3. Cause the affected kernel to mount or recover the crafted ext4 filesystem, commonly through a loop device, removable storage, VM image, recovery process, or privileged helper.
4. Trigger repeated replay failures that leak buffer_head references because iloc.bh is not released on vulnerable error paths.
5. Continue triggering the condition until kernel resources are exhausted or the system experiences memory pressure, ext4 recovery failures, or service disruption.

How to detect it

There is no reliable single artifact that proves exploitation because the bug is a kernel resource leak triggered in ext4 error paths and may resemble ordinary filesystem corruption, I/O failure, or memory pressure. Hunt for combinations of local mount activity followed by ext4 recovery errors, repeated mount failures, kernel memory pressure, or OOM killer events. Useful log sources include the kernel ring buffer, system journal, syslog/kern.log, auditd records for mount and loop-device operations, EDR telemetry for mount/losetup/qemu-nbd/guestmount execution, removable-media logs, and hypervisor or image-processing service logs. Pay particular attention to repeated attempts to mount ext4 loop images, removable drives, or VM disk images immediately before EXT4-fs errors, JBD2 recovery messages, sync failures, or OOM events. If threat hunting on source or crash artifacts, look for stack traces involving ext4_fc_replay_inode, ext4_get_fc_inode_loc, ext4_handle_dirty_metadata, sync_dirty_buffer, ext4_mark_inode_used, or ext4_iget.

• ext4_fc_replay_inode
• ext4_get_fc_inode_loc
• ext4_handle_dirty_metadata
• sync_dirty_buffer
• ext4_mark_inode_used
• ext4_iget
• EXT4-fs error
• EXT4-fs warning
• EXT4-fs (loop
• EXT4-fs: recovery complete
• JBD2: recovery failed
• Out of memory: Killed process
• invoked oom-killer
• /dev/loop
• losetup
• mount -t ext4
• guestmount
• qemu-nbd
• modprobe nbd

What your security team should do

• Prioritize patching shared Linux hosts, container platforms, virtualization hosts, forensic/malware-analysis systems, desktop fleets, and any system that mounts untrusted ext4 media or disk images.
• Deploy the vendor-fixed kernel and reboot systems into the fixed version; verify the active kernel rather than relying only on package installation status.
• Temporarily restrict local users from using loop devices, mount helpers, removable media, and untrusted filesystem images where patching is delayed.
• Review audit logs for unusual mount, losetup, modprobe, guestmount, qemu-nbd, or removable-media activity followed by ext4 errors or system memory pressure.
• Add monitoring for repeated ext4 recovery failures, kernel OOM events, and mount failures on systems that process disk images or user-supplied media.
• Because this is not currently known to be exploited and EPSS is low, handle through standard vulnerability management unless local multi-user or untrusted-media exposure increases risk.