CVE-2026-43125

What it actually does

This is a remotely reachable memory-corruption flaw in the Linux kernel Distributed Lock Manager (DLM). A length value received from DLM network messages is not properly validated before being used by dlm_dump_rsb_name() and dlm_search_rsb_tree(); if the supplied length exceeds DLM_RESNAME_MAXLEN, the kernel can write outside the intended buffer. Because the CVSS vector is network-accessible, low-complexity, unauthenticated, and requires no user interaction, successful exploitation could plausibly lead to kernel memory corruption with confidentiality, integrity, and availability impact, including system crash, corruption of kernel state, or potentially arbitrary code execution in kernel context depending on kernel build, architecture, mitigations, and exploit reliability.

Why it matters to the business

Systems using Linux kernel DLM for clustered storage, clustered filesystems, or high-availability workloads could be disrupted or compromised by malicious network messages. The most immediate operational risk is outage of cluster nodes or loss of availability for services that depend on clustered locking; in a worst case, compromise of the kernel could allow an attacker to take control of affected servers. Although EPSS is currently low and no public exploit maturity or CISA KEV listing is reported, the high CVSS score and unauthenticated network attack surface make this important for organizations running DLM-enabled clusters.

How an attack unfolds

An attacker first identifies systems exposing or participating in Linux DLM cluster communication. If the attacker can reach the DLM messaging path used by the cluster, they send a crafted DLM network message containing an overlarge resource-name length. The vulnerable kernel code accepts the attacker-controlled length without enforcing the DLM_RESNAME_MAXLEN boundary, and the malformed message reaches dlm_search_rsb_tree() through dlm_dump_rsb_name(). The kernel then performs an out-of-bounds write, corrupting memory. Depending on runtime conditions, this may immediately crash the node, destabilize cluster locking, or provide a path for more advanced kernel-level exploitation. No named threat actors, public exploit, ransomware use, or KEV exploitation have been reported in the supplied data.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the DLM length-validation fix for dlm_search_rsb_tree()/dlm_dump_rsb_name(). No exact upstream or per-distribution fixed versions were supplied, so remediation should be tracked through the relevant Linux distribution or kernel vendor advisory for this CVE. Prioritize clustered servers that load or use the DLM subsystem. If immediate patching is not possible, reduce exposure by restricting DLM/cluster communication to trusted cluster members only, enforcing host and network firewalls on cluster interconnects, isolating storage/cluster networks from user and internet-reachable networks, disabling DLM where it is not required, and ensuring only authenticated and expected nodes can participate in cluster messaging. Reboot into the fixed kernel after installation; simply installing a kernel package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a vendor-fixed build. Validate with commands such as uname -a, package-manager kernel inventory, and distribution-specific advisory tooling. Check whether DLM is present or active using lsmod | grep '^dlm', modinfo dlm, /sys/kernel/config/dlm where applicable, and cluster tooling used by the environment. Verify firewall and segmentation rules only permit cluster/DLM communication among approved cluster nodes. Review vendor changelogs or kernel package notes for the DLM length-validation fix. After rebooting into the fixed kernel, perform cluster health checks to confirm lock management and dependent clustered filesystems or HA services are operating normally.

Typical attack path

1. Identify Linux systems that are part of DLM-enabled clusters or expose DLM cluster communication to reachable networks.
2. Gain network reachability to the DLM communication path, such as from the same cluster, adjacent network, or improperly exposed management/storage segment.
3. Craft a DLM protocol message with a resource-name length greater than the expected DLM_RESNAME_MAXLEN limit.
4. Send the malformed message to the vulnerable node so the attacker-controlled length reaches dlm_dump_rsb_name() and dlm_search_rsb_tree().
5. Trigger an out-of-bounds kernel write, causing memory corruption.
6. Use the resulting condition to crash the node, disrupt cluster services, or attempt further kernel-level exploitation.

How to detect it

To determine whether exploitation may already have occurred, focus on kernel and cluster telemetry from DLM-enabled systems. Review kernel logs, system journal, crash dumps, and cluster-manager logs for unexplained kernel oops, panic, general protection fault, slab corruption, or memory-corruption events involving the dlm module or functions such as dlm_search_rsb_tree and dlm_dump_rsb_name. Correlate these events with inbound network connections or packets to cluster communication interfaces from unexpected hosts. Inspect cluster membership history for unknown nodes, repeated join/leave events, failed handshakes, malformed message errors, or sudden lockspace instability. Check for unexpected reboots, fencing events, failovers, filesystem withdraws, or clustered application outages occurring shortly after DLM-related errors. Because the supplied information does not include a public exploit, payload signature, or actor-specific tooling, detection should emphasize behavioral evidence of malformed DLM traffic and post-trigger kernel instability rather than a single definitive IOC.

• dlm_search_rsb_tree
• dlm_dump_rsb_name
• dlm:
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• BUG: unable to handle kernel
• slab-out-of-bounds
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• KASAN: use-after-free
• Call Trace:
• /sys/kernel/config/dlm
• dlm.ko

What your security team should do

• Inventory Linux systems that use DLM, clustered filesystems, or HA cluster stacks, and prioritize those with network-reachable cluster communication.
• Patch affected systems to a vendor-fixed kernel and reboot into the updated kernel as soon as operationally feasible.
• Restrict cluster/DLM traffic to trusted cluster nodes using network ACLs, host firewalls, and segmentation; do not expose cluster interconnects to general-purpose networks.
• If DLM is not required on a system, unload or disable the module and remove unnecessary cluster services.
• Increase monitoring for kernel crashes, oops/panic events, unexpected reboots, DLM errors, and cluster membership instability on DLM-enabled systems.
• Review cluster node membership and logs for unknown or unauthorized peers attempting to communicate with cluster services.
• Because no KEV listing, ransomware use, or public exploit maturity is currently reported and EPSS is low, prioritize based on actual DLM exposure while still treating internet- or broadly reachable cluster networks as urgent.