From: Aohan Mei <ljp1205831794@gmail.com>
To: gfs2@lists.linux.dev
Cc: aahringo@redhat.com, teigland@redhat.com,
linux-kernel@vger.kernel.org, Aohan Mei <henrymei@tencent.com>,
TencentOS Corvus AI <corvus@tencent.com>,
stable@vger.kernel.org
Subject: [PATCH] dlm: fix RCOM_LOOKUP length underflow
Date: Fri, 11 Sep 2026 14:53:51 +0800 [thread overview]
Message-ID: <20260911065357.3511466-1-ljp1205831794@gmail.com> (raw)
From: Aohan Mei <henrymei@tencent.com>
receive_rcom_lookup() derives the resource name length from the
peer-supplied 16-bit h_length header field:
int len = le16_to_cpu(rc_in->rc_header.h_length) -
sizeof(struct dlm_rcom);
The 3.1 receive path only bounds h_length to the range
[sizeof(struct dlm_header), DLM_MAX_SOCKET_BUFSIZE] in
dlm_validate_incoming_buffer(), and the RCOM case in
dlm_midcomms_receive_buffer_3_1() performs no further length check
despite its "length already checked" comment. A peer can therefore
send an RCOM_LOOKUP message whose h_length is smaller than
sizeof(struct dlm_rcom) (48). The subtraction is evaluated in size_t
arithmetic and wraps, and the result is assigned to an int as a
negative value.
Both consumers of that length only guard the upper bound
(len > DLM_RESNAME_MAXLEN), which a negative len passes as a signed
comparison:
- with rc_id == 0xffffffff, len reaches dlm_dump_rsb_name() ->
dlm_search_rsb_tree(), where memcpy() converts it to a huge size_t
and overflows the on-stack 64-byte key buffer;
- otherwise len reaches dlm_master_lookup() -> _dlm_master_lookup(),
where jhash() converts it to a huge u32 and reads out of bounds.
Drop the message when the computed name length falls outside
[0, DLM_RESNAME_MAXLEN], which is exactly the range valid lookups
use.
Fixes: e7fd41792fc0 ("[DLM] The core of the DLM for GFS2/CLVM")
Reported-by: TencentOS Corvus AI <corvus@tencent.com>
Cc: stable@vger.kernel.org
Assisted-by: CodeBuddy:Kimi-K3
Signed-off-by: Aohan Mei <henrymei@tencent.com>
---
fs/dlm/rcom.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/dlm/rcom.c b/fs/dlm/rcom.c
index be1a71a6303a..14d5ab658f60 100644
--- a/fs/dlm/rcom.c
+++ b/fs/dlm/rcom.c
@@ -385,6 +385,9 @@ static void receive_rcom_lookup(struct dlm_ls *ls,
int len = le16_to_cpu(rc_in->rc_header.h_length) -
sizeof(struct dlm_rcom);
+ if (len < 0 || len > DLM_RESNAME_MAXLEN)
+ return;
+
/* Old code would send this special id to trigger a debug dump. */
if (rc_in->rc_id == cpu_to_le64(0xFFFFFFFF)) {
log_error(ls, "receive_rcom_lookup dump from %d", nodeid);
--
2.43.7
next reply other threads:[~2026-09-11 6:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 6:53 Aohan Mei [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-08-21 2:28 [PATCH] dlm: fix RCOM_LOOKUP length underflow Aohan Mei
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=20260911065357.3511466-1-ljp1205831794@gmail.com \
--to=ljp1205831794@gmail.com \
--cc=aahringo@redhat.com \
--cc=corvus@tencent.com \
--cc=gfs2@lists.linux.dev \
--cc=henrymei@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.