CVE-2026-53040

What it actually does

This is a Linux kernel OCFS2 filesystem bug in the free-fragmentation information ioctl path. When OCFS2_IOC_INFO is requested with OCFS2_INFO_FL_NON_COHERENT, the kernel reads OCFS2 group descriptors without the validation performed by the coherent path. A crafted on-disk bg_bits value can therefore be used as an excessive bitmap scan limit, causing the kernel to walk beyond the valid bitmap buffer and trigger an out-of-bounds read/use-after-free condition. The most likely practical impact is local kernel crash or denial of service; depending on kernel configuration, memory layout, and exploitability of the out-of-bounds read, secondary information disclosure or further memory-corruption impact cannot be fully ruled out without product-specific analysis.

Why it matters to the business

Systems that mount or inspect untrusted OCFS2 filesystems could be crashed by a malicious disk image, removable media, virtual disk, or storage volume. For organizations using OCFS2 in clustered Linux environments, exploitation could disrupt file services, clustered workloads, or maintenance tooling that queries filesystem fragmentation information. The vulnerability is not listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, so urgency is lower than internet-exposed remote-code-execution issues, but kernel flaws affecting filesystem parsing should still be remediated because they can be triggered through operational workflows involving storage images and mounts.

How an attack unfolds

An attacker prepares an OCFS2 filesystem image with a malicious group descriptor containing an impossible bg_bits value. The attacker then causes that filesystem to be mounted or otherwise accessed on a vulnerable Linux system where OCFS2 support is available. A local user or process issues the OCFS2_IOC_INFO ioctl with the OCFS2_INFO_FL_NON_COHERENT flag to request free-fragmentation information. In the vulnerable kernel path, OCFS2 reads the descriptor via the non-coherent block-read path and fails to validate bg_bits before scanning the bitmap. The oversized value drives the bitmap scan past the valid block boundary, resulting in a kernel use-after-free/out-of-bounds read condition. The observable result is typically a kernel warning, KASAN report on instrumented kernels, oops, or system crash.

How to fix it

Upgrade to a Linux kernel version that includes the OCFS2 fix validating and clamping bg_bits during the free-fragmentation scan. Where vendor kernels are used, apply the relevant distribution kernel update rather than relying only on upstream version numbers. If immediate patching is not possible, reduce exposure by disabling or unloading the ocfs2 kernel module where OCFS2 is not required, preventing unprivileged or automated mounting of OCFS2 filesystems, blocking use of untrusted disk images/removable media, and restricting filesystem inspection tools to trusted inputs. In clustered environments that rely on OCFS2, schedule kernel updates carefully across nodes to avoid service disruption.

How to confirm the fix worked

Confirm the running kernel package contains the vendor fix for the OCFS2 bg_bits validation issue. Validate that systems which do not require OCFS2 cannot load or use the ocfs2 module. On Linux hosts, check for OCFS2 support with commands such as lsmod | grep ocfs2, modinfo ocfs2, grep ocfs2 /proc/filesystems, and findmnt -t ocfs2. Review kernel changelogs or vendor advisories for references to validating bg_bits during the OCFS2 freefrag scan. After patching, test that legitimate OCFS2 filesystems mount and that free-fragmentation query tooling operates without kernel warnings. Avoid validating with malicious filesystem images on production systems.

Typical attack path

1. Create or modify an OCFS2 filesystem image so that an on-disk group descriptor contains a bg_bits value larger than the actual bitmap capacity.
2. Deliver the crafted filesystem through a virtual disk, disk image, removable media, shared storage volume, backup artifact, or other workflow that may be mounted or inspected by Linux systems.
3. Get the crafted OCFS2 filesystem mounted or opened on a vulnerable Linux kernel with OCFS2 support enabled.
4. Invoke or trigger tooling that issues OCFS2_IOC_INFO with OCFS2_INFO_FL_NON_COHERENT to request free-fragmentation information.
5. The kernel follows the non-coherent OCFS2 ioctl path, skips descriptor validation, and scans beyond the valid bitmap buffer.
6. The system records a kernel memory-safety fault and may crash or become unstable, causing denial of service.

How to detect it

Look for evidence of prior exploitation in kernel logs, system journals, crash dumps, and audit records. Primary sources include dmesg, /var/log/kern.log, /var/log/messages, systemd-journald kernel entries, kdump/vmcore artifacts, auditd records for mount and ioctl-heavy filesystem utilities, and endpoint telemetry showing unexpected use of OCFS2 tools or modules. Search for KASAN, kernel oops, BUG, panic, or general protection fault messages with OCFS2 functions in the stack trace, especially ocfs2_info_freefrag_scan_chain, ocfs2_info_freefrag_scan_bitmap, ocfs2_info_handle_freefrag, ocfs2_info_handle_request, ocfs2_info_handle, and ocfs2_ioctl. Correlate crashes with recent mounting of OCFS2 filesystems, attachment of virtual disks, removable media insertion, backup or forensic image processing, or execution of utilities that query filesystem information. On non-KASAN production kernels, exploitation may appear only as a kernel oops, soft lockup, panic, unexplained reboot, or service outage involving OCFS2 rather than an explicit use-after-free message.

• KASAN: use-after-free in ocfs2_info_freefrag_scan_chain
• KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap
• KASAN: use-after-free in ocfs2_info_handle_freefrag
• KASAN: use-after-free in ocfs2_info_handle_request
• ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c
• ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c
• ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c
• ocfs2_info_handle_request
• ocfs2_info_handle
• ocfs2_ioctl
• OCFS2_IOC_INFO
• OCFS2_INFO_FL_NON_COHERENT
• BUG: KASAN: use-after-free
• Read of size 8 at addr
• type=OCFS2
• ocfs2

What your security team should do

• Prioritize patching Linux systems that mount OCFS2 filesystems, process disk images, operate clustered storage, or allow local users to interact with mounted OCFS2 volumes.
• Inventory hosts with OCFS2 enabled using module, filesystem, package, and mount telemetry.
• Disable or blacklist the ocfs2 module on systems that do not have a business requirement for OCFS2.
• Restrict mounting of untrusted filesystems and review workflows that automatically mount virtual disks, forensic images, backup images, or removable media.
• Monitor kernel logs for OCFS2 ioctl crashes, KASAN use-after-free reports, and call traces involving ocfs2_info_freefrag_scan_chain or ocfs2_info_handle_request.
• Treat unexpected OCFS2 kernel oops/panic events as potential malicious filesystem handling until the source image or storage volume is verified.
• Because the issue is not KEV-listed and EPSS is low, align remediation with normal kernel patch cycles unless OCFS2 is exposed to untrusted storage inputs, in which case expedite.