What is the CVSS score of CVE-2026-74401?

CVE-2026-74401 has a contested CVSS base score of 9.8 from a third party (e.g. CISA-ADP), while the vendor rates it Critical. vuln.today uses the vendor rating as authoritative.

Which versions of Linux Kernel are affected by CVE-2026-74401?

A use-after-free vulnerability in the Linux kernel's DLM (Distributed Lock Manager) could enable privilege escalation on systems running clustered filesystems such as GFS2 or OCFS2.. A patch is available.

How to fix or mitigate CVE-2026-74401?

Within 24 hours, audit Linux systems to identify those running kernel versions 5.14-6.6.144, 6.12.1-6.12.96, 6.18.0-6.18.39, or 7.0.x-7.1.4 with DLM enabled (typically GFS2 or OCFS2 deployments). Within 7 days, deploy kernel patches to staging environments and begin staged rollout of the fixed versions (6.6.145, 6.12.97, 6.18.40, or 7.1.5 per your LTS track), prioritizing production nodes; coordinate updates with clustered filesystem administrators. Within 30 days, complete patch deployment across all affected systems, verify no unpatched nodes remain in production, and document patch dates for compliance records.

Linux Kernel CVE-2026-74401

EUVD-2026-59548 CRITICAL

2026-08-15 Linux

GHSA-wgc9-j6gh-934m

Information Disclosure Linux Red Hat

Critical

Disputed · 9.8 Vendor: Linux

Severity by source

Sources disagree (Medium–Critical)

Vendor (Linux) PRIMARY

9.8 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

7.5 HIGH

Network-reachable via DLM but requires trusted cluster-peer access (PR:L) and a high-load timing race to reorder the queue (AC:H); use-after-free in kernel yields full C/I/A impact.

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Red Hat

5.5 MEDIUM

qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Aug 17, 2026 - 11:04 vuln.today

CVSS changed

Aug 17, 2026 - 06:22 NVD

9.8 (CRITICAL)

Patch available

Aug 15, 2026 - 07:19 EUVD

CVE Published

Aug 15, 2026 - 05:59 cve.org

CRITICAL 9.8

CVE Published

Aug 15, 2026 - 05:59 cve.org

UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

dlm: fix add msg handle in send_queue ordered

In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as "before(mh->seq, seq)" will stop to check for older sequence numbers that are ordered in the tail of "node->send_queue".

The side effects of not having it correct ordered regarding "before(mh->seq, seq)" are refcounting issues and use-after free.

I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.

AnalysisAI

Use-after-free in the Linux kernel's DLM (Distributed Lock Manager) subsystem stems from incorrect sequence-number ordering of message handles in a node's send_queue, which breaks the before(mh->seq, seq) tail-walk in dlm_receive_ack and leads to refcounting corruption and freeing of an in-use send buffer. It affects Linux kernels using DLM (clustered filesystems such as GFS2/OCFS2) from 5.14 onward, and is fixed in stable releases 6.6.145, 6.12.97, 6.18.40 and 7.1.5. …

Unlock full vulnerability intelligence

Risk assessment & exploitation conditions
Attack chain visualization
Remediation with exact patch versions
Threat intelligence from 22 sources
Personal watchlist & email alerts

Continue with Google Continue with GitHub

Free forever · No credit card required

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata

Access

Gain cluster-network / DLM peer access

Delivery

Flood DLM lock requests at high rate

Exploit

Force out-of-order seq in send_queue

Execution

Break dlm_receive_ack ordered ack scan

Persist

Trigger send-buffer refcount error

Impact

Use-after-free crashes node or corrupts kernel memory

Access

Gain cluster-network / DLM peer access

Delivery

Flood DLM lock requests at high rate

Exploit

Force out-of-order seq in send_queue

Execution

Break dlm_receive_ack ordered ack scan

Persist

Trigger send-buffer refcount error

Impact

Use-after-free crashes node or corrupts kernel memory

Vulnerability AssessmentAI

Exploitation	Exploitation requires the target to be running the kernel DLM subsystem in an active cluster (clustered filesystem such as GFS2 or OCFS2 with corosync/pacemaker) - DLM is not compiled into or active on default single-node systems, which is the primary limiting factor. … Additional conditions and limiting factors are described in the full assessment.
Risk Assessment	The signals conflict sharply and should be reconciled before prioritizing. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in.
Exploit Scenario	An attacker with the ability to inject or generate high-volume DLM traffic on a cluster (e.g., a compromised or rogue cluster node) drives a benchmark-like burst of lock requests that causes message handles to be queued out of sequence order. The broken ordered scan in dlm_receive_ack then decrements refcounts incorrectly and frees a send buffer still in use, yielding a use-after-free that can crash the node or potentially be shaped toward kernel memory corruption. …
Remediation	Vendor-released patch: update to a fixed stable kernel - 6.6.145, 6.12.97, 6.18.40, or 7.1.5 (7.2-rc1 in mainline) - matching your maintained branch, or apply the backported commits ae9e534e502a / 6369619f1b66 / 712714f818d8 / 4d45250b1d22 / d2248cb70c07 from https://git.kernel.org/stable/. … Detailed patch versions, workarounds, and compensating controls in full report.

Recommended ActionAI

Within 24 hours, audit Linux systems to identify those running kernel versions 5.14-6.6.144, 6.12.1-6.12.96, 6.18.0-6.18.39, or 7.0.x-7.1.4 with DLM enabled (typically GFS2 or OCFS2 deployments). …

Threat intelligence, references, and detailed analysis are available after sign-in.