From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: Ryusuke Konishi <konishi.ryusuke@gmail.com>,
syzbot+c37bed40868932d790e9@syzkaller.appspotmail.com,
wuyankun <wuyankun@uniontech.com>,
Viacheslav Dubeyko <slava@dubeyko.com>,
Sasha Levin <sashal@kernel.org>
Subject: [PATCH 6.1.y 2/2] nilfs2: reject invalid block index in GC ioctl
Date: Tue, 25 Aug 2026 21:17:50 -0400 [thread overview]
Message-ID: <20260826011750.958726-2-sashal@kernel.org> (raw)
In-Reply-To: <20260826011750.958726-1-sashal@kernel.org>
From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
[ Upstream commit a1735eae55448bc79c2da6593455791e886f6ed8 ]
Syzbot reported list corruption caused by a double list_add_tail() call on
bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers().
Analysis revealed that the root cause was the insertion of a page/folio
with a page index of ULONG_MAX into the page cache via the GC ioctl.
filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(),
repeatedly detects a dirty folio with a page index of ULONG_MAX due to
index wrap-around, leading to duplicate processing of dirty buffers.
As a preparatory step, the GC ioctl loads the page/folio of the block to
be moved during GC and inserts it into the page cache based on information
in the nilfs_vdesc structure passed as an argument. Normally, this does
not cause issues because the user-space GC library configures the
nilfs_vdesc structure properly. However, since there is no range check on
the parameters determining the page index, a request with artificially
crafted parameters -- such as those generated by Syzbot -- can result in a
page/folio being inserted with a page index of ULONG_MAX, triggering the
above problem.
This resolves the issue by checking the ranges of 'vd_offset' and
'vd_vblocknr' in the nilfs_vdesc structure that determine the page index,
thereby preventing the invalid page/folio insertions.
Reported-by: syzbot+c37bed40868932d790e9@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c37bed40868932d790e9
Fixes: 7942b919f732 ("nilfs2: ioctl operations")
Cc: wuyankun <wuyankun@uniontech.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/nilfs2/ioctl.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/fs/nilfs2/ioctl.c b/fs/nilfs2/ioctl.c
index b0e7c26f0b93f..4e964549bc4ce 100644
--- a/fs/nilfs2/ioctl.c
+++ b/fs/nilfs2/ioctl.c
@@ -513,6 +513,7 @@ static int nilfs_ioctl_get_bdescs(struct inode *inode, struct file *filp,
* Return: 0 on success, or one of the following negative error codes on
* failure:
* * %-EEXIST - Block conflict detected.
+ * * %-EINVAL - Invalid virtual block descriptor.
* * %-EIO - I/O error.
* * %-ENOENT - Requested block doesn't exist.
* * %-ENOMEM - Insufficient memory available.
@@ -522,15 +523,30 @@ static int nilfs_ioctl_move_inode_block(struct inode *inode,
struct list_head *buffers)
{
struct buffer_head *bh;
+ __u64 limit_blkidx = (__u64)inode->i_sb->s_maxbytes >> inode->i_blkbits;
int ret;
- if (vdesc->vd_flags == 0)
+ /*
+ * vblocknr 0 is reserved as an invalid pointer. Also, limit_blkidx
+ * ensures that the page index converted from vd_vblocknr never
+ * overflows the page cache limit and respects the architecture's bmap
+ * key width.
+ */
+ if (unlikely(vdesc->vd_vblocknr == 0 ||
+ vdesc->vd_vblocknr >= limit_blkidx))
+ return -EINVAL;
+
+ if (vdesc->vd_flags == 0) {
+ if (unlikely(vdesc->vd_offset >= limit_blkidx))
+ return -EINVAL;
+
ret = nilfs_gccache_submit_read_data(
inode, vdesc->vd_offset, vdesc->vd_blocknr,
vdesc->vd_vblocknr, &bh);
- else
+ } else {
ret = nilfs_gccache_submit_read_node(
inode, vdesc->vd_blocknr, vdesc->vd_vblocknr, &bh);
+ }
if (unlikely(ret < 0)) {
if (ret == -ENOENT)
--
2.53.0
prev parent reply other threads:[~2026-08-26 1:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 12:20 FAILED: patch "[PATCH] nilfs2: reject invalid block index in GC ioctl" failed to apply to 6.1-stable tree gregkh
2026-08-26 1:17 ` [PATCH 6.1.y 1/2] nilfs2: correct return value kernel-doc descriptions for ioctl functions Sasha Levin
2026-08-26 1:17 ` Sasha Levin [this message]
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=20260826011750.958726-2-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=konishi.ryusuke@gmail.com \
--cc=slava@dubeyko.com \
--cc=stable@vger.kernel.org \
--cc=syzbot+c37bed40868932d790e9@syzkaller.appspotmail.com \
--cc=wuyankun@uniontech.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.