gfs2.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Alexander Aring <aahringo@redhat.com>
To: teigland@redhat.com
Cc: aahringo@redhat.com, gfs2@lists.linux.dev
Subject: [PATCH RESEND dlm/next 3/8] dlm: validate userspace lock resource name length
Date: Tue,  1 Sep 2026 13:47:10 -0400	[thread overview]
Message-ID: <20260901174715.3825582-4-aahringo@redhat.com> (raw)
In-Reply-To: <20260901174715.3825582-1-aahringo@redhat.com>

From: Samuel Moelius <sam.moelius@trailofbits.com>

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 <aahringo@redhat.com>
Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
Signed-off-by: Alexander Aring <aahringo@redhat.com>
---
 fs/dlm/user.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/fs/dlm/user.c b/fs/dlm/user.c
index cd7e142ca670d..0b0a7e1bd1095 100644
--- a/fs/dlm/user.c
+++ b/fs/dlm/user.c
@@ -512,6 +512,7 @@ static ssize_t device_write(struct file *file, const char __user *buf,
 			    size_t count, loff_t *ppos)
 {
 	struct dlm_user_proc *proc = file->private_data;
+	size_t name_payload = 0;
 	struct dlm_write_request *kbuf;
 	int error;
 
@@ -545,6 +546,7 @@ static ssize_t device_write(struct file *file, const char __user *buf,
 
 		if (count > sizeof(struct dlm_write_request32))
 			namelen = count - sizeof(struct dlm_write_request32);
+		name_payload = namelen;
 
 		k32buf = (struct dlm_write_request32 *)kbuf;
 
@@ -561,7 +563,13 @@ static ssize_t device_write(struct file *file, const char __user *buf,
 
 		compat_input(kbuf, k32buf, namelen);
 		kfree(k32buf);
+	} else {
+		if (count > sizeof(*kbuf))
+			name_payload = count - sizeof(*kbuf);
 	}
+#else
+	if (count > sizeof(*kbuf))
+		name_payload = count - sizeof(*kbuf);
 #endif
 
 	/* do we really need this? can a write happen after a close? */
@@ -571,6 +579,15 @@ static ssize_t device_write(struct file *file, const char __user *buf,
 		goto out_free;
 	}
 
+	if (kbuf->cmd == DLM_USER_LOCK &&
+	    !(kbuf->i.lock.flags & DLM_LKF_CONVERT)) {
+		if (kbuf->i.lock.namelen > name_payload ||
+		    kbuf->i.lock.namelen > DLM_RESNAME_MAXLEN) {
+			error = -EINVAL;
+			goto out_free;
+		}
+	}
+
 	error = -EINVAL;
 
 	switch (kbuf->cmd)
-- 
2.43.0


  parent reply	other threads:[~2026-09-01 17:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 17:47 [PATCH RESEND dlm/next 0/8] dlm: pending fixes based on v7.3-rc1 Alexander Aring
2026-09-01 17:47 ` [PATCH RESEND dlm/next 1/8] dlm: gate dlm_plock device on CAP_SYS_ADMIN Alexander Aring
2026-09-01 17:47 ` [PATCH RESEND dlm/next 2/8] dlm: require CAP_SYS_ADMIN for dlm-monitor device Alexander Aring
2026-09-01 17:47 ` Alexander Aring [this message]
2026-09-01 17:47 ` [PATCH RESEND dlm/next 4/8] dlm: fix buffer overflow from negative len in dlm_search_rsb_tree Alexander Aring
2026-09-01 17:47 ` [PATCH RESEND dlm/next 5/8] dlm: validate lock modes in recovery messages Alexander Aring
2026-09-01 17:47 ` [PATCH RESEND dlm/next 6/8] dlm: fix NULL pointer dereference in dlm_dump_rsb_name() Alexander Aring
2026-09-01 17:47 ` [PATCH RESEND dlm/next 7/8] dlm: wait for outstanding SRCU callbacks to complete in exit paths Alexander Aring
2026-09-01 17:47 ` [PATCH RESEND dlm/next 8/8] dlm: fix variable key length lookup Alexander Aring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260901174715.3825582-4-aahringo@redhat.com \
    --to=aahringo@redhat.com \
    --cc=gfs2@lists.linux.dev \
    --cc=teigland@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).