kernel/git/next/linux-next.git/fs/dlm, branch master

dlm: wait for outstanding SRCU callbacks to complete in exit paths

2026-09-02T16:52:20+00:00

The dlm_lowcomms_exit() and dlm_midcomms_exit() iterate over the srcu protected connection and node hash tables and hand each element to call_srcu() for deferred freeing (connection_release() and midcomms_node_release()). call_srcu() is asynchronous: the callbacks are invoked only after an SRCU grace period, which may happen after the exit function has already returned. These exit functions are reached from exit_dlm() on module unload. Once they return, module teardown continues and the module text may be unloaded while call_srcu() callbacks are still pending. When such a callback finally runs, it executes freed module code and touches the static SRCU domains that are being torn down, resulting in a use-after-free. Add an srcu_barrier() after the call_srcu() loop in each exit function to wait for all outstanding callbacks of the respective SRCU domain to complete before returning. In dlm_midcomms_exit() the barrier is issued before dlm_lowcomms_exit() so that node callbacks are drained prior to tearing down the lower layer. Signed-off-by: Zqiang Acked-by: Alexander Aring Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: fix variable key length lookup

2026-09-02T14:01:52+00:00

Before commit 6c648035cbe7 ("dlm: switch to use rhashtable for rsbs") the rsb hashtable was dynamic key length. Accidentally it was changed to switch to static key length which can end in different results. We fixing this back to the original behaviour by adding the necessary functionality to rhashtable to handle the objects and lookups as dynamic key lengths. Fixes: 6c648035cbe7 ("dlm: switch to use rhashtable for rsbs") Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: fix NULL pointer dereference in dlm_dump_rsb_name()

2026-09-02T14:01:52+00:00

The function dlm_dump_rsb_name() is called from receive_rcom_lookup() when a debug dump is requested via a special RCOM_LOOKUP message with rc_id == 0xFFFFFFFF. The resource name passed to dlm_dump_rsb_name() comes from the received message. There is no guarantee that an RSB with this name exists in the local hash table. dlm_search_rsb_tree() returns 0 when the RSB is found and stores a valid pointer in r. When the lookup fails, it returns -EBADR and leaves r NULL. The current error handling is inverted: if (!error) goto out; As a result, dlm_dump_rsb() is called only when the lookup fails and r is NULL, resulting in a NULL pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 2d90354027ad ("dlm: merge toss and keep hash table lists into one list") Acked-by: Alexander Aring Signed-off-by: Danila Chernetsov Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: validate lock modes in recovery messages

2026-09-02T14:01:52+00:00

The DLM recovery path restores lock state from rcom_lock messages received from remote nodes. The lock modes in these messages are copied directly into the local lkb state without validating that they are within the valid DLM lock mode range. The rest of the DLM code assumes that lkb_rqmode and lkb_grmode contain valid lock modes. In particular, LVB callback handling in dlm_may_skip_callback() uses lock modes as indexes into the dlm_lvb_operations array: dlm_lvb_operations[prev_mode + 1][mode + 1] An invalid lock mode received during recovery could therefore result in an out-of-bounds read during subsequent LVB callback processing. Validate rl_rqmode and rl_grmode before storing them into the local LKB state. This preserves the lock mode invariant required by the rest of the DLM code. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e7fd41792fc0 ("[DLM] The core of the DLM for GFS2/CLVM") Acked-by: Alexander Aring Signed-off-by: Danila Chernetsov Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: fix buffer overflow from negative len in dlm_search_rsb_tree

2026-09-02T14:01:51+00:00

commit 080e5563f878c ("dlm: validate length in dlm_search_rsb_tree") only checks for len > DLM_RESNAME_MAXLEN, which does not catch negative values. While the input 'len' can be negative and a negative int passed to memcpy() is implicitly converted to a large size_t, causing a stack buffer overflow on the key[] array. Fix this by changing the 'len' parameter type from int to unsigned int. This ensures negative values from callers are implicitly converted to large unsigned values that are caught by the existing len > DLM_RESNAME_MAXLEN check. Acked-by: Alexander Aring Signed-off-by: Joseph Qi Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: validate userspace lock resource name length

2026-09-02T14:01:51+00:00

The DLM userspace device accepts a flexible resource name after `struct dlm_write_request`. `device_write()` bounded the total write size, but did not verify that `i.lock.namelen` was covered by the bytes actually supplied by the write. A short `DLM_USER_LOCK` request can therefore claim a full `DLM_RESNAME_MAXLEN` resource name while providing no name bytes. The request path later hashes and copies the claimed name length, reading past the `memdup_user_nul()` allocation. Reject non-conversion lock requests whose claimed resource name length exceeds the flexible name payload supplied with the write. Valid lock requests with complete names are unchanged. Track the payload length before compat conversion so 32-bit requests keep using their own request header size. Assisted-by: Codex:gpt-5.5-cyber-preview Acked-by: Alexander Aring Signed-off-by: Samuel Moelius Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: require CAP_SYS_ADMIN for dlm-monitor device

2026-09-02T14:01:51+00:00

monitor_device_open() in fs/dlm/user.c performs only atomic_inc(&dlm_monitor_opened) and sets dlm_monitor_unused = 0; it does no capability check. monitor_device_close() does atomic_dec_and_test(&dlm_monitor_opened) and, when the count reaches zero, calls dlm_stop_lockspaces() — which stops every lockspace on the node. The miscdevice is also registered with no .mode field. Attack chain (when the device node is reachable by an unprivileged opener — see mitigation note below): 1. attacker open("/dev/dlm-monitor") with no cap check; the global counter goes 0 -> 1 2. attacker close(fd); atomic_dec_and_test reaches zero again and dlm_stop_lockspaces() runs -> every DLM lockspace on the local node is stopped. Other cluster members then observe the node losing its lockspaces (membership / recovery side effects), so the impact is not strictly local to GFS2 / OCFS2 / lvmlockd / cluster-md workloads on this node. variant: attacker holds the fd open indefinitely to suppress the intended stop when dlm_controld later closes its own fd (inverse abuse — recovery / shutdown stalls) Mitigation: devtmpfs creates /dev/dlm-monitor as 0600 root:root on a stock kernel, so unprivileged open is blocked by the node mode, not by a kernel cap check. The gap is real wherever the node is reachable (udev MODE=0666, container bind-mount, fd via SCM_RIGHTS, or any setup where dlm_controld shares its monitor fd). Reproduction (kernel 7.2.0-rc3, dlm loaded, no live lockspace): # ./exploit_h3 # as root [*] lockspace devices present: 0 [!!!] AUTH BYPASS: opened /dev/dlm-monitor, no cap check (fd=3) [VULNERABLE] monitor open auth bypass demonstrated $ setpriv --reuid 65534 --regid 65534 ./exploit_h3 [OK ] open denied: Permission denied # node 0600, not cap check The destructive close path is opt-in in the PoX (--i-know-it-stops-lockspaces); we did not drive it here. Driving the close path on a node with active lockspaces would stop them; on this throw-away node there are none, but we keep the opt-in gate so the same PoX is safe to re-run on production-like clusters. Fix: gate monitor_device_open() on capable(CAP_SYS_ADMIN) and set .mode = 0600 on monitor_device, matching the dlm_controld-only intended usage. Acked-by: Alexander Aring Signed-off-by: Haofeng Li Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: gate dlm_plock device on CAP_SYS_ADMIN

2026-09-02T14:01:51+00:00

fs/dlm/plock.c registers /dev/dlm_plock via a miscdevice whose file_operations has no .open callback and whose .mode field is unset. The kernel therefore performs no capability check on open, and any process that can open the node becomes an unprivileged plock daemon with full read+write access to the pending-plock queue. Attack chain (when the device node is reachable by an unprivileged opener — see mitigation note below): 1. attacker open("/dev/dlm_plock") succeeds with no cap check 2. dev_read() drains pending plock requests straight to user space, leaking dlm_plock_info fields: fsid, number (resource id / inode), start, end, owner, pid, ex, wait 3. dev_write() matches an attacker-supplied dlm_plock_info against a pending op on recv_list (matched on fsid+number+ owner+pid+start+end+ex+wait) and memcpy()'s it into the in-kernel op, including a forged .rv == 0 4. when a matched op exists, the forged result is then applied: for async ops (op->data != NULL), dlm_plock_callback() runs posix_lock_file(); for sync ops, the requester wakes and proceeds as if the cluster had granted the lock. Either way the requester ends up holding a POSIX lock without a real DLM grant, or sees attacker-chosen rv that breaks lock correctness. With no pending op on recv_list, dev_write() still returns sizeof(info) but does nothing beyond a pr_debug ("dlm dev_write no op ...") — so a syntactically accepted write does not by itself prove an applied grant. Mitigation: on a stock kernel, devtmpfs creates /dev/dlm_plock as 0600 root:root, so steps 1-4 are only reachable where the node is exposed to a less privileged principal — e.g. udev MODE=0666, container bind-mount of the node, or an fd passed via SCM_RIGHTS. The in-kernel capability gap is real regardless of node mode. Reproduction (kernel 7.2.0-rc3, dlm loaded): # ./exploit_h2 # as root [*] node /dev/dlm_plock mode=0600 uid=0 gid=0 [!!!] AUTH BYPASS: opened with no capability check (fd=3) [!!!] FORGE ACCEPTED: kernel accepted forged plock result (rv=0); pending ops are grant-forgeable [VULNERABLE] open + read-leak + grant-forge demonstrated The "FORGE ACCEPTED" line means dev_write() returned sizeof(info), i.e. the write path is reachable and the version check passed; it does not by itself mean a grant was applied. Demonstrating an actual forged grant requires a concurrent plock op on recv_list to match against. $ setpriv --reuid 65534 --regid 65534 ./exploit_h2 [OK ] open denied: Permission denied # devtmpfs 0600, not a kernel cap check Fix: add a .open callback that requires CAP_SYS_ADMIN, and set .mode = 0600 on the miscdevice so the explicit expectation matches the devtmpfs default and survives future defaults. Acked-by: Alexander Aring Signed-off-by: Haofeng Li Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: init per node debugfs before add to node hash

2026-05-08T13:38:03+00:00

Avoiding potential issues when a node is added to the hash but the debugfs is not NULL or IS_ERR() so a potential iteration over the hash and debugfs_remove() will not fail like in dlm_midcomms_exit(). However dlm_midcomms_exit() will be called in module init/exit function and the hash should be empty anyway at those stages. We change the behavior as cleanup to avoid potential issues. Reported-by: Ginger Closes: https://lore.kernel.org/gfs2/CAGp+u1ZE7UsQ4sSUHBKQXU8x3M_jwK=ek1urSjEtd3jXQGFmVg@mail.gmail.com Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: fix add msg handle in send_queue ordered

2026-05-08T13:38:03+00:00

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. Fixes: 489d8e559c659 ("fs: dlm: add reliable connection if reconnect") Signed-off-by: Alexander Aring Signed-off-by: David Teigland