Skip to main content
VulnerabilityPublished Updated

CVE-2026-74401: Linux kernel · dlm: fix add msg handle in send_queue ordered

Affects Linux kernelSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 9.8 Critical · fixed in d2248cb70c070f8f04762872772e155b59016f17 : patch Linux kernel as a priority.

Data as of 30 Oct 2026, 12:49 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.

Thin evidence

One scorer or none
CVSS scores by source
CNA (Linux)CVSS 3.19.8
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers can reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in d2248cb70c070f8f04762872772e155b59016f17, ae9e534e502a0f48c12baf83608c5de0ff0eab11, 6369619f1b665f12d8c99cc6ff733c64eb08b22e +3
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 15 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 489d8e559c6596eb08e16447d9830bc39afbe54e, < d2248cb70c070f8f04762872772e155b59016f17
Fixed in
  • d2248cb70c070f8f04762872772e155b59016f17
LinuxLinuxAffected
  • ≥ 489d8e559c6596eb08e16447d9830bc39afbe54e, < ae9e534e502a0f48c12baf83608c5de0ff0eab11
Fixed in
  • ae9e534e502a0f48c12baf83608c5de0ff0eab11
LinuxLinuxAffected
  • ≥ 489d8e559c6596eb08e16447d9830bc39afbe54e, < 6369619f1b665f12d8c99cc6ff733c64eb08b22e
Fixed in
  • 6369619f1b665f12d8c99cc6ff733c64eb08b22e
LinuxLinuxAffected
  • ≥ 489d8e559c6596eb08e16447d9830bc39afbe54e, < 712714f818d83373847874ab0f8e426be79296cf
Fixed in
  • 712714f818d83373847874ab0f8e426be79296cf
LinuxLinuxAffected
  • ≥ 489d8e559c6596eb08e16447d9830bc39afbe54e, < 482606fea302d8bab86901d7426c3716980d99a8
Fixed in
  • 482606fea302d8bab86901d7426c3716980d99a8
LinuxLinuxAffected
  • ≥ 489d8e559c6596eb08e16447d9830bc39afbe54e, < 4d45250b1d22960f86d83245be188b16e456218b
Fixed in
  • 4d45250b1d22960f86d83245be188b16e456218b

Description

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.

References

Community reviews

Loading reviews…