CVE-2026-53309

What it actually does

This is an off-by-one out-of-bounds read in the Linux kernel OCFS2 Distributed Lock Manager region-comparison logic. The vulnerable loop in dlm_match_regions() iterates one element past the valid qr_regions array boundary when comparing local and remote lock regions. In practical terms, a reachable code path can cause the kernel to read adjacent memory it should not access. Depending on kernel build, memory layout, and runtime conditions, the impact is most likely kernel instability, kernel warning/oops, or denial of service; limited information exposure may be possible in some circumstances, but there is no public evidence of reliable privilege escalation or remote code execution.

Why it matters to the business

Organizations running OCFS2 clustered filesystems on affected Linux kernels could experience node crashes, cluster instability, application downtime, or storage service disruption if the vulnerable DLM code path is triggered. The risk is lower for systems that do not load or use OCFS2. EPSS is low, the issue is not listed in CISA KEV, is not known to be used in ransomware, and there is no known public exploit maturity, so remediation should be handled through normal kernel patch cycles unless OCFS2 is business-critical or exposed to untrusted cluster participants.

How an attack unfolds

An attacker would need a way to cause OCFS2 DLM region comparison activity on an affected kernel, typically by interacting with an OCFS2 clustered filesystem or by influencing lock/resource activity from a participating cluster node. The attacker triggers lock-region comparisons where the vulnerable loop evaluates region entries. Because the loop uses an inclusive upper bound, the kernel reads one entry beyond the valid region array. If that out-of-bounds read touches invalid or protected memory, the kernel may produce an oops, panic, or node instability. If it reads adjacent valid memory, the operation may continue silently or produce abnormal behavior. There are no known public exploitation techniques showing reliable code execution; the most plausible abuse case is denial of service against systems actively using OCFS2/DLM.

How to fix it

Upgrade affected Linux kernels to a vendor-supported build that includes the OCFS2/DLM fix changing the dlm_match_regions() loop bound from <= to <. Because no universal fixed package versions were provided, use distribution advisories and kernel changelogs for the exact fixed kernel release. If immediate patching is not possible, reduce exposure by disabling OCFS2 where it is not required, unloading the ocfs2 module if safe, preventing automatic loading of unused OCFS2 modules, restricting cluster/DLM communication to trusted nodes only, and avoiding untrusted participation in OCFS2 clusters. For critical clustered storage deployments, plan rolling kernel updates according to vendor guidance to avoid storage or quorum disruption.

How to confirm the fix worked

Confirm exposure by checking whether OCFS2 is installed, loadable, loaded, or actively mounted. Useful checks include lsmod for ocfs2-related modules, findmnt or mount output for OCFS2 filesystems, /proc/filesystems for ocfs2 support, and distribution package metadata for the running kernel version. Confirm remediation by verifying the running kernel is at or above the vendor-fixed release or that the vendor changelog includes the OCFS2/DLM dlm_match_regions() off-by-one fix. After patching, reboot into the fixed kernel and re-check uname -r, loaded modules, and active OCFS2 mounts. For source-built kernels, confirm the affected loop in fs/ocfs2/dlm/dlmmaster.c uses a strict less-than comparison for the region iteration rather than an inclusive comparison.

Typical attack path

1. Identify a Linux system or cluster using OCFS2 and the OCFS2 Distributed Lock Manager.
2. Gain the ability to interact with the OCFS2 filesystem or operate from a cluster participant that can influence DLM lock activity.
3. Generate filesystem or lock-region operations that reach dlm_match_regions().
4. Trigger the off-by-one region comparison so the kernel reads past the valid qr_regions array.
5. Cause kernel warnings, oops, panic, node instability, or potentially observe secondary effects from abnormal DLM behavior.

How to detect it

To determine whether this was already triggered, review kernel logs, persistent journal logs, crash dumps, and cluster/fencing logs from OCFS2 nodes. Look for kernel oops, panic, KASAN, UBSAN, or slab out-of-bounds reports referencing OCFS2, DLM, or dlm_match_regions(). Also investigate unexplained node reboots, storage cluster fencing, OCFS2 mount failures, lock-manager instability, or application outages that coincide with OCFS2/DLM warnings. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore artifacts, cluster manager logs, and monitoring alerts for node panics or fencing. There are no known attacker-specific network indicators or payload signatures for this vulnerability; detection is primarily based on kernel fault artifacts and abnormal OCFS2/DLM behavior.

• dlm_match_regions
• ocfs2/dlm
• OCFS2
• BUG: KASAN: slab-out-of-bounds
• slab-out-of-bounds in dlm_match_regions
• kernel BUG at fs/ocfs2/dlm
• general protection fault
• BUG: unable to handle kernel paging request
• kernel panic
• Oops:
• /var/crash
• /proc/fs/ocfs2
• fs/ocfs2/dlm/dlmmaster.c

What your security team should do

• Inventory Linux systems using OCFS2, prioritizing clustered storage nodes and systems where ocfs2 modules are loaded or OCFS2 filesystems are mounted.
• Patch affected systems through the normal kernel update process, prioritizing production OCFS2 clusters ahead of systems where OCFS2 is merely present but unused.
• If OCFS2 is not required, disable or blacklist the ocfs2 module and remove unused cluster filesystem packages where operationally safe.
• Restrict OCFS2 cluster and DLM communication to trusted cluster members and management networks only.
• Monitor kernel logs for OCFS2/DLM crashes, KASAN out-of-bounds reports, kernel oops events, unexpected reboots, or cluster fencing events.
• Review vendor advisories for exact fixed kernel package versions, since fixed versions are distribution-specific.
• Because this is not KEV-listed and has low EPSS with no known exploit maturity, treat as important hardening for OCFS2 users rather than an emergency internet-wide remediation event.