External risk intelligence

Linux Kernel DLM Refcounting and Use-After-Free Vulnerability.

CVE advisorySeverity: CRITICAL (CVSS 9.8)

CVE-2026-74401

The vulnerability resides in the Distributed Lock Manager (DLM) component of the Linux kernel. DLM is typically used in clustered environments for internal node communication and is rarely exposed directly to the public internet.

Use After Free

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This Linux kernel vulnerability, related to message ordering in the Distributed Lock Manager (DLM), could lead to memory corruption issues if triggered by a high volume of network requests. While specific exploitation scenarios were observed in experimental settings, the main concern at this time is confirming its relevance and exposure within our environment.

Messaging order issue in Linux kernel component.
Potential for memory corruption if exposed to high load.
Confirm relevance and exposure to our environment.

Attack Path

How an attacker could exploit the issue

An attacker could potentially exploit this vulnerability by triggering a large volume of Distributed Lock Manager (DLM) messages, particularly within a benchmark scenario. This could lead to sequence ordering issues within the DLM's send queue, causing refcounting problems and a use-after-free condition. The provided context indicates this was reproducible in an experimental DLM branch using a userspace benchmark with io_uring.

Entry condition: Network access to trigger DLM messages.
Trigger point: High volume of DLM messages.
Resulting risk: Refcounting and use-after-free.

Live Threat

Current exploitation, exposure, and threat context

The Linux kernel's Distributed Lock Manager (DLM) could experience refcounting issues and use-after-free vulnerabilities when a large number of network messages are processed in a specific benchmark scenario. This could impact system stability and data integrity.

System memory and stability.
Improper message ordering during high load.
Potential for system crashes.

Operational Fix

Recommended remediation, mitigation, and detection steps

The Linux kernel's Distributed Lock Manager (DLM) component is affected by this vulnerability. Infrastructure or platform teams managing Linux systems are likely responsible for addressing this issue. The first practical step is to identify all systems running the affected Linux kernel version, determine if DLM is in use and exposed, and then ascertain the business criticality of those systems before planning remediation.

Identify Linux infrastructure owners.
Verify DLM usage and exposure.
Plan remediation based on criticality.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the Linux kernel's Distributed Lock Manager (DLM)?

DLM is a component of the Linux kernel designed to coordinate access to shared resources across multiple computers in a cluster. It ensures that data remains consistent when different nodes need to modify the same files or database entries simultaneously. You will primarily find it in high-availability environments, such as clustered filesystems or complex server networks, where synchronized communication between machines is essential for maintaining system stability.

How does CVE-2026-74401 cause memory corruption?

This vulnerability is a memory management flaw involving how the kernel tracks the order of network messages. When the system processes a high volume of requests, it may fail to properly sequence messages in its queue. This error leads to refcounting issues, where the system loses track of how many tasks are using a specific piece of memory, eventually resulting in a use-after-free condition where the system inadvertently interacts with memory that has already been released.

Do I need to be under a massive benchmark load to trigger this?

While the flaw was identified during intense benchmark scenarios involving high volumes of network traffic, it specifically requires an environment where the DLM is actively receiving a flood of requests. It is not triggered by standard, low-volume communication. The issue stems from the internal ordering of the send queue, meaning the vulnerability requires a specific, sustained pattern of network activity to manifest the underlying sequencing error.

Is my system at risk based on Halo Surface Signal?

According to Halo Surface Signal, the risk is unlikely for most systems. Because the Distributed Lock Manager is designed for internal node-to-node communication within a cluster, it is rarely exposed to the public internet. If your systems are not part of an internet-facing cluster, the surface area for this type of network-based attack is significantly restricted, as the communication typically occurs over private, internal network segments.

What should I do first if I run systems with this kernel?

Your first step is to verify whether your environment actively utilizes DLM. If DLM is in use, determine the business criticality of those specific clusters. Once you have an inventory of affected systems, coordinate with your infrastructure or platform teams to evaluate if those nodes are reachable over broader network segments. Focus your assessment on high-traffic nodes where heavy message processing is common, and monitor for official updates for your specific Linux distribution.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.