CVE-2026-43076

What it actually does

This is a Linux kernel use-after-free in the OCFS2 filesystem driver. When an OCFS2 inode with inline data is read from disk, the kernel validates several inode fields but, in vulnerable versions, does not verify that the inode size is no larger than the inline-data buffer capacity. A malformed or corrupted OCFS2 filesystem can therefore cause directory-walking code to read past the valid inline-data area and operate on freed memory. Successful exploitation can crash the kernel and may allow local code execution with kernel privileges, depending on allocator state, kernel hardening, and the attacker’s ability to shape memory.

Why it matters to the business

Systems that mount OCFS2 filesystems, especially from removable media, disk images, shared storage, or other untrusted sources, can be crashed or potentially compromised at the kernel level by a malformed filesystem. This can cause service outages, data integrity risk, and possible full host takeover. The current public exploitation likelihood appears low based on the low EPSS score, no known CISA KEV listing, no ransomware association, and no reported exploit maturity, but the impact is high for environments that use OCFS2 because kernel compromise bypasses normal application security boundaries.

How an attack unfolds

An attacker prepares a malicious OCFS2 filesystem image or storage volume containing an inode that uses inline data but advertises an inode size larger than the actual inline-data capacity. The attacker then needs the target system to mount or otherwise access that filesystem, for example through removable media, a disk image, shared block storage, or an administrative workflow that inspects untrusted filesystems. When the Linux kernel reads the crafted inode, vulnerable OCFS2 validation accepts the inconsistent metadata. Later, OCFS2 directory iteration trusts the oversized inode size, walks beyond the inline-data buffer, and reaches freed memory while checking directory entries. The immediate result may be a kernel warning, KASAN report, oops, or panic. With sufficient control over heap layout and absent effective mitigations, the memory corruption could be developed into local privilege escalation or kernel-mode code execution.

How to fix it

Upgrade to a Linux kernel version or vendor-maintained kernel package that includes the OCFS2 fix validating inline-data inode size during inode read. Because no exact fixed versions were provided, use the relevant distribution or kernel vendor advisory for the corrected package and verify that the patch adding the i_size <= id_count validation in ocfs2_validate_inode_block() is present. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the OCFS2 kernel module if not required, preventing unprivileged or automated mounting of OCFS2 filesystems, restricting access to removable media and disk-image mount workflows, and treating OCFS2 volumes from untrusted sources as hostile. In high-assurance environments, require filesystem inspection in isolated sandboxes or disposable virtual machines before mounting on production hosts.

How to confirm the fix worked

Confirm that systems are running a kernel package that includes the OCFS2 inline-data size validation fix. Check whether OCFS2 support is present or loaded using kernel configuration and module state, such as CONFIG_OCFS2_FS, lsmod, modinfo, and distribution package metadata. Review mount tables and filesystem inventories for active OCFS2 usage. If a vendor test or safe reproducer is available, validate in a non-production lab that a malformed OCFS2 inode with inline data and i_size greater than id_count is rejected during inode validation rather than causing a kernel oops, KASAN use-after-free report, or panic. Also confirm that compensating controls, such as module blacklisting or mount restrictions, remain effective after reboot and kernel updates.

Typical attack path

1. Identify a target system or workflow that has OCFS2 support enabled and may mount or inspect OCFS2 filesystems.
2. Create a malformed OCFS2 filesystem image or volume with inline-data inode metadata where i_size exceeds id_count.
3. Deliver the crafted filesystem through removable media, a disk image, virtual disk, shared storage, backup artifact, or other local-access mechanism.
4. Cause a user, administrator, automation job, or system service to mount or traverse the malicious OCFS2 filesystem.
5. Trigger directory iteration on the crafted inode so the kernel reads beyond the inline-data buffer.
6. Leverage the resulting use-after-free for denial of service, or attempt kernel privilege escalation if exploitation is reliable in the target kernel configuration.

How to detect it

To determine whether this may already have been exploited, review kernel logs, system journals, crash dumps, and EDR telemetry for OCFS2-related crashes or memory-safety reports, especially shortly after mounting removable media, disk images, shared storage, or cluster filesystems. Useful log sources include dmesg, /var/log/kern.log, /var/log/messages, systemd-journald kernel records, kdump/vmcore artifacts, hypervisor console logs, and any crash reporting pipeline. Look for KASAN use-after-free reports, kernel oopses, BUG or panic messages, and stack traces mentioning OCFS2 functions such as ocfs2_check_dir_entry, ocfs2_dir_foreach_blk_id, or ocfs2_validate_inode_block. Correlate those events with mount commands, loop-device creation, udev activity, file-manager automount behavior, backup or forensic tooling, and access to newly attached block devices or disk images. Absence of these indicators does not prove non-exploitation, because a successful kernel-level exploit may suppress logging or crash before logs are flushed.

• ocfs2_check_dir_entry
• ocfs2_dir_foreach_blk_id
• ocfs2_validate_inode_block
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• use-after-free in ocfs2_check_dir_entry
• OCFS2
• ocfs2
• kernel BUG at fs/ocfs2
• RIP: 0010:ocfs2_check_dir_entry
• Call Trace:
• mount.ocfs2
• fsck.ocfs2
• /sbin/mount.ocfs2
• /usr/sbin/mount.ocfs2
• /sbin/fsck.ocfs2
• /usr/sbin/fsck.ocfs2
• CONFIG_OCFS2_FS
• ocfs2.ko

What your security team should do

• Prioritize patching systems that mount OCFS2, process disk images, use shared cluster storage, or permit administrators or automation to inspect untrusted filesystems.
• Inventory OCFS2 exposure by identifying hosts with the OCFS2 module available, loaded, or active in mounted filesystems.
• If OCFS2 is not business-critical, disable or blacklist the OCFS2 module and remove unnecessary OCFS2 tooling from hardened systems.
• Restrict mounting of removable media, virtual disks, and externally supplied filesystem images to isolated analysis hosts or sandboxes.
• Monitor kernel logs for OCFS2 errors, KASAN use-after-free reports, kernel oopses, and panics associated with OCFS2 directory traversal.
• Review recent incidents involving unexplained Linux host crashes after mounting or scanning disk images, removable storage, or shared OCFS2 volumes.
• Track distribution advisories for the corrected kernel package because fixed versions were not supplied in the source data.