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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-15T06:22:42.120Z",
  "pubdate": "2026-08-15T06:22:42.120Z",
  "executiveSummary": "A use-after-free and reference counting vulnerability exists in the Distributed Lock Manager (DLM) subsystem of the Linux kernel. The vulnerability arises due to incorrect message sequence ordering within the transmission queue under high-load benchmarking scenarios, such as those utilizing io_uring. Specifically, the mh->seq field within message handles is not properly ordered relative to the oldest sequence numbers, violating the assumptions relied upon by dlm_receive_ack. When dlm_receive_ack evaluates sequence numbers using the before(mh->seq, seq) macro, it prematurely halts checks for older sequence numbers positioned incorrectly at the tail of the node->send_queue. This logical flaw leads to improper lifecycle management of memory buffers, resulting in severe refcounting errors and use-after-free conditions. The impact includes potential kernel memory corruption, system instability, and arbitrary code execution capabilities for a privileged or network-positioned attacker capable of generating heavy DLM traffic. Exploitation requires triggering high-volume request scenarios that stress the DLM messaging subsystem to induce the queue ordering failure.",
  "technicalDetails": "The vulnerability resides in the Linux kernel Distributed Lock Manager (DLM) network messaging handling logic, specifically within the management and ordering of the node->send_queue structure. Under high-throughput benchmark scenarios generating intense network traffic, DLM message handles (mh) are inserted into the transmission queue in a state where the sequence numbers (mh->seq) fail to maintain strict chronological ordering from oldest to newest.\nThe core vulnerability mechanism involves the dlm_receive_ack function, which relies heavily on the before(mh->seq, seq) macro to iterate through pending messages and acknowledge sequence numbers. The architectural design of dlm_receive_ack assumes that sequence numbers are strictly ordered within node->send_queue. Because out-of-order sequence numbers can reside at the tail of the queue, the evaluation logic invoked by before(mh->seq, seq) encounters unexpected gaps and prematurely terminates its traversal. As a result, older sequence numbers requiring processing or acknowledgment are skipped entirely.\nThis failure in sequence processing disrupts the underlying memory buffer reference counting mechanism. Buffers that should remain allocated and tracked are prematurely dereferenced or freed while references to them persist in internal tracking structures. Consequently, subsequent operations attempting to access these buffers trigger use-after-free conditions. Attack flow involves flooding the DLM subsystem with asynchronous requests—such as through io_uring-based user space benchmarks—to induce race conditions and queue misordering. Post-exploitation impact encompasses kernel panics, denial of service, and potential privilege escalation or arbitrary kernel code execution via heap corruption of freed buffer memory."
}