CVE-2026-43288

What it actually does

This is a local Linux kernel denial-of-service flaw in the ext4 filesystem mount path. During ext4 initialization, ext4_mb_init() can validate a block bitmap before ext4_percpu_param_init() has initialized required per-CPU counters. If bitmap validation fails, ext4_mark_group_bitmap_corrupted() attempts to update an uninitialized counter, causing a kernel page fault and panic. The impact is availability only: successful triggering can crash the host, but it does not directly provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

An attacker with local ability to present or mount a malformed ext4 filesystem could crash an affected Linux system, causing service interruption, workload failure, node reboot, or loss of availability for applications running on that host. The risk is lower than remotely exploitable kernel flaws because exploitation requires local access and specific filesystem-mount conditions. EPSS is low, it is not listed in CISA KEV, and no public exploit maturity is indicated, but systems that process untrusted disk images, removable media, VM images, container volumes, or user-supplied filesystem artifacts are more exposed operationally.

How an attack unfolds

An attacker prepares an ext4 filesystem with features and metadata conditions that cause block bitmap validation to fail during mount, such as a crafted or corrupted ext4 image using small block sizes and quota/project features. The attacker then causes an affected kernel to mount that filesystem locally, either by directly invoking a mount operation where permitted or by abusing a workflow that automatically mounts supplied disks, images, or volumes. During mount, ext4 initializes multiblock allocation before the relevant per-CPU counters are initialized. When validation detects the bad bitmap, the ext4 error-handling path attempts to update the uninitialized free-cluster counter. This results in a kernel page fault in percpu_counter_add_batch(), leading to an oops or panic and denial of service for the host.

How to fix it

Update the Linux kernel to a vendor-supported build that includes the ext4 fix moving ext4_percpu_param_init() before ext4_mb_init(). Because no fixed product versions were provided, use the relevant distribution or kernel vendor advisory to identify the first fixed package for each maintained release stream. Where immediate patching is not possible, reduce exposure by preventing untrusted users and automation from mounting ext4 filesystems, disabling or tightly controlling automatic mounting of removable media and disk images, restricting CAP_SYS_ADMIN and mount privileges, isolating image-processing workloads, and avoiding mounting untrusted ext4 images on production hosts.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed version for this issue, not merely that an updated package is installed on disk. Validate with kernel package inventory and the active runtime kernel version after reboot. For source-based kernels, verify that ext4_percpu_param_init() is invoked before ext4_mb_init() in the ext4 superblock initialization path. In a non-production test system only, regression validation can use a crafted ext4 filesystem that previously triggered the panic and confirm the mount no longer crashes the kernel. Also confirm that controls preventing untrusted filesystem mounts are enforced, including mount privilege restrictions and disabled automount behavior where applicable.

Typical attack path

1. Gain local access or access to a workflow that causes Linux to mount attacker-controlled ext4 media, disk images, or volumes.
2. Create or modify an ext4 filesystem so that block bitmap validation fails during mount, commonly involving quota/project features and crafted filesystem metadata.
3. Present the malformed filesystem to an affected Linux kernel.
4. Trigger a mount of the filesystem.
5. The ext4 mount path calls ext4_mb_init() before the per-CPU counters are initialized.
6. The bad bitmap validation path calls ext4_mark_group_bitmap_corrupted(), which updates an uninitialized counter.
7. The kernel faults in percpu_counter_add_batch(), causing an oops or panic and interrupting host availability.

How to detect it

Look for evidence of prior kernel crashes during ext4 mount operations. Relevant log sources include kernel ring buffer output, system journal, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore records, hypervisor reset events, and EDR telemetry around mount, losetup, tune2fs, mkfs.ext4, and filesystem image handling. Search for ext4 bitmap checksum validation failures immediately followed by kernel oops, page fault, panic, or reboot events. Correlate these with recent mount activity, loop-device creation, removable media insertion, newly attached block devices, or processing of user-supplied disk images. Because this flaw is a denial-of-service condition and does not create a persistent implant by itself, detection relies primarily on crash artifacts, kernel stack traces, and suspicious filesystem-mount activity rather than network indicators.

• EXT4-fs error
• ext4_validate_block_bitmap
• bad block bitmap checksum
• BUG: unable to handle page fault
• Oops: 0000
• percpu_counter_add_batch
• ext4_mark_group_bitmap_corrupted
• ext4_read_block_bitmap
• mb_group_bb_bitmap_alloc
• ext4_mb_add_groupinfo
• ext4_mb_init_backend
• ext4_mb_init
• __ext4_fill_super
• ext4_fill_super
• comm mount
• tune2fs -O quota,project
• mkfs.ext4 -F -q -b 1024
• mount /dev/

What your security team should do

• Prioritize patching Linux systems that mount untrusted storage, VM images, forensic images, removable media, backup volumes, or user-supplied filesystem artifacts.
• Inventory systems running affected Linux kernel builds and map them to vendor-fixed kernel packages.
• Reboot after kernel updates to ensure the fixed kernel is actually running.
• Restrict local mount capabilities, especially CAP_SYS_ADMIN, privileged containers, loop-device access, and automount services exposed to untrusted users or inputs.
• Review image-processing, virtualization, CI, backup, and forensic workflows for automatic mounting of ext4 filesystems from untrusted sources.
• Monitor kernel logs for ext4 bitmap validation errors followed by kernel oops or panic traces involving percpu_counter_add_batch(), ext4_mark_group_bitmap_corrupted(), or ext4_validate_block_bitmap().
• Treat observed crashes matching this stack trace as possible malicious triggering if they occur after mounting external, user-supplied, or newly attached ext4 media.