CVE-2026-53043

What it actually does

This is an out-of-bounds read in the Linux kernel OCFS2 distributed lock manager (DLM). A crafted DLM_QUERY_REGION network message can set qr_numregions to a value greater than the maximum supported region count, causing dlm_match_regions() to read beyond the fixed qr_regions buffer. A related boundary-condition issue can also read one entry past the valid range. The primary impact is kernel memory disclosure or kernel instability from invalid memory access in OCFS2/DLM code paths. Exploitation requires the vulnerable OCFS2/DLM functionality to be present and reachable by an attacker able to send crafted cluster/DLM network messages.

Why it matters to the business

Organizations using OCFS2 clustered filesystems may face risk of node crashes, service disruption, or exposure of kernel memory contents if untrusted or compromised systems can communicate with the OCFS2 cluster network. The issue is not currently listed in CISA KEV, has low EPSS, and has no public exploit maturity indicated, so broad internet-scale exploitation is less likely; however, clustered storage environments are often business-critical, making even denial-of-service outcomes operationally significant.

How an attack unfolds

An attacker first needs network reachability to the OCFS2/o2net/DLM communication path, typically from a host on the same cluster network or from a compromised cluster-adjacent system. The attacker sends a malformed DLM_QUERY_REGION message with qr_numregions set above the supported O2NM_MAX_REGIONS limit, or otherwise crafted to trigger the off-by-one comparison path. On vulnerable kernels, the DLM region-matching logic trusts the supplied count and iterates past the end of the qr_regions array. Depending on memory layout and runtime conditions, this can result in reading adjacent kernel memory, producing incorrect comparisons, leaking data through protocol behavior, or causing a kernel fault and disrupting the OCFS2 node.

How to fix it

Upgrade to a Linux kernel version that includes the OCFS2/DLM fixes validating qr_numregions in dlm_match_regions() and correcting the off-by-one loop condition. If vendor kernels are used, apply the corresponding distribution security update rather than relying only on upstream version numbers. Where immediate patching is not possible, restrict OCFS2/o2net/DLM traffic to trusted cluster nodes only, isolate cluster interconnect networks, block untrusted access to the OCFS2 cluster communication ports, and disable or unload OCFS2/DLM components on systems that do not require them. Treat compromised or untrusted cluster members as high risk because the attack surface is primarily reachable from cluster-adjacent systems.

How to confirm the fix worked

Confirm that the running kernel includes the vendor fix for this CVE or the upstream patches that add a qr_numregions bounds check and fix the dlm_match_regions() loop condition. Verify the active runtime kernel after reboot, not only the installed package version. Check whether OCFS2 is loaded or in use with commands such as lsmod, findmnt, mount, and modinfo ocfs2. Validate network exposure by confirming that OCFS2/o2net/DLM communication is limited to expected cluster nodes and is blocked from user, server, and internet-facing networks. If available, use vendor advisories or kernel changelogs to confirm the presence of the OCFS2/DLM patch in the deployed kernel build.

Typical attack path

1. Identify systems running a vulnerable Linux kernel with OCFS2 and DLM/o2net functionality enabled.
2. Obtain network access to the OCFS2 cluster communication path or compromise a host that can send cluster messages.
3. Craft a DLM_QUERY_REGION message with an invalid qr_numregions value greater than O2NM_MAX_REGIONS or a boundary value that triggers the off-by-one read.
4. Send the malformed message to a vulnerable node over the OCFS2/DLM network channel.
5. Trigger out-of-bounds reads in dlm_match_regions(), potentially causing kernel memory exposure, abnormal DLM behavior, or node instability.

How to detect it

Look for evidence of attempted or successful exploitation in kernel logs, system journals, crash dumps, and network telemetry from OCFS2 cluster interconnects. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k, dmesg, kdump/vmcore analysis, firewall logs, and packet captures or flow logs for o2net/DLM traffic. Hunt for kernel faults or warnings involving ocfs2, dlm_match_regions(), o2net, DLM_QUERY_REGION handling, out-of-bounds reads, KASAN reports, general protection faults, BUG/Oops traces, or unexpected node disconnect/reconnect events. Network-side detection is difficult without protocol-aware inspection, but suspicious signs include malformed or unusually frequent DLM query-region messages, OCFS2 cluster traffic from non-cluster IP addresses, or cluster messages immediately preceding kernel crashes. If a node crashed, preserve vmcore/kdump artifacts and correlate crash time with cluster-network connections and any new or unauthorized cluster member activity.

• dlm_match_regions
• DLM_QUERY_REGION
• qr_numregions
• O2NM_MAX_REGIONS
• ocfs2/dlm
• ocfs2_dlm
• ocfs2_dlmfs
• o2net
• OCFS2
• DLM
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• kernel BUG at fs/ocfs2
• Oops:
• Kernel panic
• /var/crash/vmcore
• /proc/fs/ocfs2

What your security team should do

• Prioritize patching Linux systems that use OCFS2 clustered filesystems or have ocfs2, ocfs2_dlmfs, or related DLM modules loaded.
• Restrict OCFS2/o2net/DLM cluster traffic to explicitly trusted cluster-node IP addresses using host firewalls, network ACLs, or segmentation controls.
• Inventory systems with OCFS2 support enabled, even if not actively mounted, and remove or blacklist unused kernel modules where operationally safe.
• Review cluster membership and investigate any unexpected node, IP address, or host communicating with the OCFS2 cluster interconnect.
• Monitor kernel logs for OCFS2, DLM, o2net, BUG, Oops, panic, slab, KASAN, or general protection fault messages following cluster-network activity.
• Because exploitation maturity is currently reported as none and EPSS is low, align emergency response to actual OCFS2 exposure rather than patching all Linux systems with equal urgency.