CVE-2026-43075

What it actually does

This is a Linux kernel memory corruption vulnerability in the OCFS2 filesystem implementation. When handling inline data writes, ocfs2_try_to_write_inline_data trusts the on-disk id_count field from an inode block. If an attacker can cause the kernel to mount or process a corrupted OCFS2 filesystem where id_count exceeds the real maximum inline-data capacity, a write path such as copy_file_range/splice fallback can overflow past the inode block buffer in ocfs2_write_end_inline. The result is an out-of-bounds kernel memory write, which may cause kernel crashes, memory corruption, privilege escalation, or potentially arbitrary kernel code execution depending on exploitability and kernel hardening.

Why it matters to the business

Systems that allow local users, containers, automation jobs, or removable/loop-mounted images to mount or interact with untrusted OCFS2 filesystems could be exposed to local privilege escalation or denial of service. Successful exploitation could let a low-privileged user disrupt critical Linux hosts or gain elevated control over them. The EPSS score is currently very low, the trend is flat, there is no known CISA KEV listing, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely; however, kernel memory corruption bugs should still be prioritized on multi-user Linux servers, virtualization hosts, CI/build systems, and any environment that processes untrusted disk images.

How an attack unfolds

An attacker first needs local execution or a way to supply a crafted OCFS2 filesystem image to a system that will mount or process it. The attacker corrupts OCFS2 inode metadata so that the inline data id_count value is larger than the physical inline-data capacity of the inode block. After the filesystem is mounted, the attacker triggers a write path that reaches ocfs2_write_end_inline, for example through copy_file_range, splice-related fallback behavior, or another write operation affecting inline data. Because the vulnerable kernel trusts the corrupted id_count, it copies more data than the inode block buffer can safely contain, writing past the end of the buffer into adjacent kernel memory. In the simplest case this causes a kernel panic or filesystem-related crash; with sufficient control over heap layout and kernel mitigations, the memory corruption may be shaped into privilege escalation.

How to fix it

Upgrade to a Linux kernel build that includes the OCFS2 fix adding an id_count upper-bound validation in ocfs2_validate_inode_block. Because no exact fixed package versions were provided, obtain the corrected kernel from the relevant Linux distribution or kernel vendor security advisory and reboot into the patched kernel. If immediate patching is not possible, reduce exposure by preventing untrusted users from mounting filesystems, disabling or restricting loop-device access where feasible, blocking automount behavior for untrusted media/images, avoiding processing of untrusted OCFS2 images, and unloading or blacklisting the ocfs2 module on systems that do not require OCFS2. These mitigations reduce attack surface but do not replace a kernel update.

How to confirm the fix worked

Confirm that systems are running a vendor kernel that includes the OCFS2 inode block validation fix, not merely that an updated package is installed. Validate by checking the active kernel version after reboot and comparing it against the vendor advisory or changelog for the OCFS2 id_count validation patch. On systems where OCFS2 is not needed, confirm the ocfs2 module is not loaded and cannot be auto-loaded by untrusted users. Review whether local users can mount loop devices or arbitrary filesystem images. For exposure testing, security teams can inventory kernels with OCFS2 support enabled and identify hosts where /proc/filesystems or loaded modules show ocfs2 availability.

Typical attack path

1. Obtain local code execution or the ability to provide a filesystem image that the target system will mount or inspect.
2. Create or modify an OCFS2 filesystem image with a malformed inode inline-data id_count value exceeding the valid maximum.
3. Mount the crafted OCFS2 filesystem, commonly via a loop device or another local block-device path.
4. Trigger a write operation against affected inline data, such as a copy_file_range or splice-related file copy path.
5. Cause ocfs2_write_end_inline to perform an out-of-bounds write past the inode block buffer.
6. Leverage the resulting kernel memory corruption for denial of service or, in a more advanced exploit, local privilege escalation.

How to detect it

Look for evidence that untrusted or unusual OCFS2 filesystems were mounted and then followed by kernel memory-corruption symptoms. Relevant sources include kernel logs, systemd journal, auditd mount records, sudo logs, shell history, EDR telemetry, crash dumps, kdump/vmcore artifacts, and filesystem image handling logs from backup, CI, forensic, or sandbox tooling. Search for KASAN, BUG, panic, general protection fault, slab corruption, or kernel oops messages referencing ocfs2_write_end_inline, ocfs2_write_end_nolock, ocfs2_try_to_write_inline_data, ocfs2_validate_inode_block, memcpy_from_folio, vfs_copy_file_range, do_splice_direct, or iter_file_splice_write. Also investigate unexpected losetup activity, mount commands using -t ocfs2, loading of the ocfs2 module, and OCFS2 mounts on systems that do not normally use clustered filesystems. Because the vulnerability is local and exploitation may leave only crash or mount artifacts, absence of network indicators does not rule out exploitation.

• ocfs2_write_end_inline
• ocfs2_write_end_nolock
• ocfs2_try_to_write_inline_data
• ocfs2_validate_inode_block
• memcpy_from_folio
• vfs_copy_file_range
• do_splice_direct
• iter_file_splice_write
• KASAN: write OOB
• KASAN: use-after-free Write
• BUG: KASAN
• out-of-bounds write
• mount -t ocfs2
• type=ocfs2
• filesystem type 'ocfs2'
• modprobe ocfs2
• insmod ocfs2
• losetup
• /dev/loop
• ocfs2.ko

What your security team should do

• Prioritize patching multi-user Linux systems, virtualization hosts, CI/build workers, storage nodes, and systems that mount or inspect untrusted disk images.
• Deploy the vendor-fixed kernel and reboot; verify the running kernel is the patched version.
• If OCFS2 is not operationally required, disable or blacklist the ocfs2 kernel module to remove the attack surface.
• Restrict mount, loop-device, and filesystem-image handling capabilities to trusted administrators only.
• Hunt for recent kernel crashes or KASAN reports involving ocfs2_write_end_inline, ocfs2_write_end_nolock, copy_file_range, splice, or out-of-bounds writes.
• Monitor for unexpected OCFS2 mounts, loop-device creation, or user-controlled disk images on servers where OCFS2 is not expected.
• Treat any confirmed exploitation as a host compromise scenario if privilege escalation is suspected; preserve memory/crash artifacts and perform full incident response.