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.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - The UAF is triggered in dlm_receive_ack when processing DLM_ACK packets from remote cluster peers over lowcomms TCP/SCTP port 21064 (receive_from_sock -> dlm_process_incoming_buffer -> dlm_midcomms_receive_buffer_3_2); wire ACK sequence numbers directly drive premature dlm_mhandle_delete on the victim.
AC:L - The send_queue ordering race in midcomms_new_msg_cb is hit under heavy concurrent DLM traffic; an attacker controls both sides by flooding lock requests from a cluster peer (io_uring benchmark per fix author) while sending ACKs, without depending on timing they cannot influence.
PR:N - DLM has no authentication or TLS; the only gate is source IP matching a configured cluster node in addr_to_nodeid. A compromised cluster peer or attacker on the cluster network needs no Unix account or local privileges on the victim to deliver crafted DLM_ACK packets.
UI:N - No victim user action is required; ACKs and lock traffic are processed automatically on already-running HA cluster nodes (GFS2/OCFS2/Pacemaker) by DLM receive and send workqueues without any interactive step.
S:U - Impact is confined to kernel heap and refcount corruption within the victim node's kernel address space; no VM, IOMMU, or sandbox boundary is crossed—standard kernel UAF enabling privilege escalation on the same host.
C:H - Misordered send_queue causes dlm_receive_ack to skip or prematurely free mhandles via call_rcu/dlm_mhandle_release while references still exist; UAF reads from freed slab objects enable heap grooming and arbitrary kernel memory disclosure.
I:H - Premature dlm_mhandle_delete releases in-flight mh->msg buffers and corrupts kref counts while commit paths still dereference the handle; UAF write primitives via reclaimed slab data can hijack kernel control flow per DLM UAF scoring guidance.
A:H - Refcounting corruption and use-after-free in dlm_receive_ack reliably cause KASAN splats, kernel oopses, and cluster-wide availability loss when DLM on HA nodes handling GFS2/OCFS2 lock traffic crashes or hangs.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - The UAF is triggered in dlm_receive_ack when processing DLM_ACK packets from remote cluster peers over lowcomms TCP/SCTP port 21064 (receive_from_sock -> dlm_process_incoming_buffer -> dlm_midcomms_receive_buffer_3_2); wire ACK sequence numbers directly drive premature dlm_mhandle_delete on the victim.
AC:L - The send_queue ordering race in midcomms_new_msg_cb is hit under heavy concurrent DLM traffic; an attacker controls both sides by flooding lock requests from a cluster peer (io_uring benchmark per fix author) while sending ACKs, without depending on timing they cannot influence.
PR:N - DLM has no authentication or TLS; the only gate is source IP matching a configured cluster node in addr_to_nodeid. A compromised cluster peer or attacker on the cluster network needs no Unix account or local privileges on the victim to deliver crafted DLM_ACK packets.
UI:N - No victim user action is required; ACKs and lock traffic are processed automatically on already-running HA cluster nodes (GFS2/OCFS2/Pacemaker) by DLM receive and send workqueues without any interactive step.
S:U - Impact is confined to kernel heap and refcount corruption within the victim node's kernel address space; no VM, IOMMU, or sandbox boundary is crossed—standard kernel UAF enabling privilege escalation on the same host.
C:H - Misordered send_queue causes dlm_receive_ack to skip or prematurely free mhandles via call_rcu/dlm_mhandle_release while references still exist; UAF reads from freed slab objects enable heap grooming and arbitrary kernel memory disclosure.
I:H - Premature dlm_mhandle_delete releases in-flight mh->msg buffers and corrupts kref counts while commit paths still dereference the handle; UAF write primitives via reclaimed slab data can hijack kernel control flow per DLM UAF scoring guidance.
A:H - Refcounting corruption and use-after-free in dlm_receive_ack reliably cause KASAN splats, kernel oopses, and cluster-wide availability loss when DLM on HA nodes handling GFS2/OCFS2 lock traffic crashes or hangs.
CVSS 3.1