CVE-2026-43068

What it actually does

CVE-2026-43068 is a Linux kernel ext4 filesystem flaw in the block allocator path. When ext4 encounters a corrupted block bitmap or corrupted block group, ext4_mb_load_buddy() can return an error before later code checks whether the group is marked corrupt. As a result, ext4_mb_find_by_goal() may continue requesting allocation from a block group that should have been avoided, causing repeated delayed block allocation failures. The practical technical effect is local denial of service and filesystem availability impact, including failed writes and potential data loss messages from the kernel. The CVSS vector indicates local access, low attack complexity, low privileges, no user interaction, and high availability impact.

Why it matters to the business

Systems using affected Linux kernels with ext4 filesystems may experience write failures, filesystem errors, service disruption, and potential data loss conditions if the vulnerable allocator path is triggered. This is most relevant for servers, embedded devices, appliances, containers or virtual machines backed by ext4, and systems that process removable, virtual, or otherwise untrusted ext4 media. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no public exploit maturity reported, and has a very low EPSS score of 0.00117 with no meaningful 30-day increase, so broad internet-scale exploitation is unlikely; however, the operational impact can still be serious on systems where local users or workloads can write heavily to ext4-backed storage.

How an attack unfolds

An attacker needs local access with the ability to perform filesystem write operations, or a path to cause the system to mount and use a malformed or already-corrupted ext4 filesystem. The attacker targets an ext4 volume where a block group or block bitmap is corrupt, then triggers file creation or write activity that causes delayed allocation. The vulnerable kernel enters the ext4 block allocation path, attempts to use the goal block group, receives an error while loading buddy allocation metadata, and fails to reliably skip the corrupt group at the correct point. Repeated allocation attempts can then fail with EFSCORRUPTED-style errors, producing kernel log messages about delayed block allocation failure and possible data loss. The end result is denial of service for applications relying on the filesystem, failed writes, and possible filesystem recovery requirements such as remounting read-only, fsck, restoring from backups, or kernel upgrade.

How to fix it

Upgrade to a Linux kernel version that includes the ext4 fix for avoiding allocation from corrupted block groups in ext4_mb_find_by_goal(). Because exact fixed package versions were not provided, use the security advisory from the operating system or kernel distribution vendor and install the latest kernel update that references this CVE or the upstream ext4 allocator fix. Reboot into the updated kernel after installation; merely installing the package is not sufficient if the old kernel remains running. As mitigations until patching is complete, restrict local shell and container access on systems with ext4-backed storage, avoid mounting untrusted ext4 images or removable media, mount untrusted filesystems read-only where possible, ensure backups are current, and run filesystem checks on volumes showing EXT4-fs corruption messages. If errors are already present, schedule maintenance to unmount the filesystem and run fsck.ext4/e2fsck according to vendor guidance before returning the volume to production use.

How to confirm the fix worked

Confirm exposure by checking the running kernel version with uname -a and comparing it against the vendor advisory for this issue, not only the installed package inventory. Confirm ext4 usage with findmnt -t ext4, lsblk -f, or /proc/mounts. After patching and rebooting, verify the system is running the fixed kernel and that affected ext4 filesystems no longer emit repeated delayed allocation failure messages during representative write workloads. Review dmesg, journalctl -k, and persistent system logs for EXT4-fs messages. For filesystems that previously reported corruption, validate clean status using fsck.ext4/e2fsck during an approved maintenance window with the filesystem unmounted or mounted read-only as appropriate.

Typical attack path

1. Obtain local code execution or access to a workload that can write to an ext4-backed filesystem.
2. Identify or introduce a condition where an ext4 block group or block bitmap is corrupt, such as through a crafted filesystem image, removable media, virtual disk, or pre-existing filesystem corruption.
3. Trigger file creation, append, overwrite, or delayed allocation activity on the affected ext4 filesystem.
4. Cause the kernel ext4 allocator to enter ext4_mb_find_by_goal() and attempt allocation from the corrupt block group.
5. Observe repeated delayed block allocation failures, kernel EXT4-fs errors, application write failures, service disruption, or filesystem degradation.

How to detect it

To determine whether this was already triggered, review kernel and system logs for ext4 allocation and corruption errors. Useful sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, hypervisor console logs for virtual machines, and appliance serial or console logs. Focus on repeated EXT4-fs messages for the same device, especially delayed block allocation failures, error 117, EFSCORRUPTED-related failures, block bitmap validation failures, and references to ext4_mb_generate_buddy. Correlate timestamps with application write errors, database or service crashes, remounts as read-only, fsck activity, storage errors, or recent mounting of external/virtual ext4 media. There are no reliable network indicators because exploitation is local and filesystem-specific. Threat intelligence currently does not indicate known exploitation by named threat actors, KEV listing, or ransomware campaigns for this issue.

• EXT4-fs
• Delayed block allocation failed
• This should not happen!! Data will be lost
• error 117
• error count since last fsck
• initial error at time
• last error at time
• ext4_mb_generate_buddy
• ext4_mb_find_by_goal
• ext4_mb_load_buddy
• ext4_validate_block_bitmap
• EXT4_MB_GRP_BBITMAP_CORRUPT
• EFSCORRUPTED

What your security team should do

• Prioritize kernel updates for systems that use ext4 for critical application data, shared multi-user environments, container hosts, virtualization hosts, embedded systems, and systems that mount removable or user-supplied disk images.
• Reboot systems after installing the fixed kernel and verify the running kernel version, because this vulnerability remains present until the updated kernel is active.
• Search kernel logs fleet-wide for EXT4-fs delayed allocation failures and ext4_mb_generate_buddy errors to identify systems that may already have triggered the vulnerable condition or have filesystem corruption.
• Restrict the ability to mount filesystem images or removable ext4 media to trusted administrators, and prefer read-only mounts for untrusted media.
• Ensure recent, restorable backups exist for ext4-backed critical data before remediation or filesystem repair activities.
• For systems showing repeated EXT4-fs corruption messages, treat the host as operationally degraded: preserve logs, reduce write activity if possible, schedule fsck, and prepare for recovery from backup if data loss is confirmed.
• Monitor vendor advisories for exact fixed kernel package versions because no product-specific fixed versions were supplied in the input.