From: Tao Cui <cui.tao@linux.dev>
To: linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk,
brauner@kernel.org
Cc: jack@suse.cz, andrii.nakryiko@gmail.com,
linux-kernel@vger.kernel.org, cui.tao@linux.dev,
Tao Cui <cuitao@kylinos.cn>,
stable@vger.kernel.org
Subject: [PATCH] fs: reject U64_MAX as last_mnt_id in listmount()
Date: Mon, 7 Sep 2026 14:57:23 +0800 [thread overview]
Message-ID: <20260907065724.1355551-1-cui.tao@linux.dev> (raw)
From: Tao Cui <cuitao@kylinos.cn>
listmount() uses mnt_id_req::param as a pagination cursor: on forward
iteration do_listmount() starts from the first mount with an id strictly
greater than last_mnt_id. The sanity check in prepare_klistmount() only
rejects ids in the range [1, MNT_UNIQUE_ID_OFFSET]; U64_MAX passes the
check, and incrementing it wraps back to 0, so mnt_find_id_at() restarts
from the leftmost mount in the namespace every time.
A caller paging with last_mnt_id set to U64_MAX therefore always gets
the same first batch of ids returned and can never advance to the end of
the list:
# base: every call returns the same first batch
listmount(param=U64_MAX) = 8 ids: 2147483886 2147483888 ...
# patched:
listmount(param=U64_MAX) = -1 EINVAL
Reject U64_MAX up front together with the other invalid ids.
Fixes: b4c2bea8ceaa ("add listmount(2) syscall")
Cc: stable@vger.kernel.org
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
---
fs/namespace.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/namespace.c b/fs/namespace.c
index 8d4009cfbf5b..cb95b855f78b 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -6108,6 +6108,9 @@ static inline int prepare_klistmount(struct klistmount *kls, struct mnt_id_req *
/* The first valid unique mount id is MNT_UNIQUE_ID_OFFSET + 1. */
if (last_mnt_id != 0 && last_mnt_id <= MNT_UNIQUE_ID_OFFSET)
return -EINVAL;
+ /* U64_MAX would wrap to 0 and restart the iteration. */
+ if (last_mnt_id == U64_MAX)
+ return -EINVAL;
kls->last_mnt_id = last_mnt_id;
--
2.43.0
next reply other threads:[~2026-09-07 6:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 6:57 Tao Cui [this message]
2026-09-07 9:45 ` [PATCH] fs: reject U64_MAX as last_mnt_id in listmount() Jan Kara
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=20260907065724.1355551-1-cui.tao@linux.dev \
--to=cui.tao@linux.dev \
--cc=andrii.nakryiko@gmail.com \
--cc=brauner@kernel.org \
--cc=cuitao@kylinos.cn \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.