fs/jfs/jfs_dtree.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-)
Syzbot reported a general protection fault in inode_set_ctime_current.
This resulted from the following circumstances: when creating a new file
via dtInsert, BT_GETSEARCH may yield a pointer to a dtroot which is
embedded directly in the jfs_inode_info. When finally dtInsertEntry is
called, if the freelist field or any next field of a slot of the dtpage
is corrupted, this may result in memory corruption of the parent
directory inode.
In this case the i_sb field was corrupted, which raised the gpf when
in inode_set_ctime_current i_sb was dereferenced to access s_time_gran.
I tested the patch using the syzbot reproducer and doing some basic
filesystem operations on a fresh jfs fs, such as "cp -r /usr/include/
/mnt/jfs/" and "rm -r /mnt/jfs/include/n*"
Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
Reported-by: syzbot+cd7590567cc388f064f3@syzkaller.appspotmail.com
Closes: https://syzbot.org/bug?extid=cd7590567cc388f064f3
---
fs/jfs/jfs_dtree.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c
index 0ab83bb7bbdf..e37278596afe 100644
--- a/fs/jfs/jfs_dtree.c
+++ b/fs/jfs/jfs_dtree.c
@@ -170,8 +170,8 @@ static void dtGetKey(dtpage_t * p, int i, struct component_name * key,
static int ciGetLeafPrefixKey(dtpage_t * lp, int li, dtpage_t * rp,
int ri, struct component_name * key, int flag);
-static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
- ddata_t * data, struct dt_lock **);
+static int dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
+ ddata_t * data, struct dt_lock **);
static void dtMoveEntry(dtpage_t * sp, int si, dtpage_t * dp,
struct dt_lock ** sdtlock, struct dt_lock ** ddtlock,
@@ -891,7 +891,8 @@ int dtInsert(tid_t tid, struct inode *ip,
lv->length = 1;
dtlck->index++;
- dtInsertEntry(p, index, name, &data, &dtlck);
+ if ((rc = dtInsertEntry(p, index, name, &data, &dtlck)))
+ return rc;
/* linelock stbl of non-root leaf page */
if (!(p->header.flag & BT_ROOT)) {
@@ -3625,9 +3626,10 @@ static void dtGetKey(dtpage_t * p, int i, /* entry index */
* function: allocate free slot(s) and
* write a leaf/internal entry
*
- * return: entry slot index
+ * * return: 0 - success;
+ * errno - failure;
*/
-static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
+static int dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
ddata_t * data, struct dt_lock ** dtlock)
{
struct dtslot *h, *t;
@@ -3649,6 +3651,10 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
/* allocate a free slot */
hsi = fsi = p->header.freelist;
+ if (fsi >= ((p->header.flag & BT_ROOT) ? DTROOTMAXSLOT : p->header.maxslot)) {
+ jfs_err("Encountered corrupted dtpage before insert");
+ return -EIO;
+ }
h = &p->slot[fsi];
p->header.freelist = h->next;
--p->header.freecnt;
@@ -3697,6 +3703,10 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
while (klen) {
/* get free slot */
fsi = p->header.freelist;
+ if (fsi >= ((p->header.flag & BT_ROOT) ? DTROOTMAXSLOT : p->header.maxslot)) {
+ jfs_err("Encountered corrupted dtpage before insert");
+ return -EIO;
+ }
t = &p->slot[fsi];
p->header.freelist = t->next;
--p->header.freecnt;
@@ -3774,6 +3784,8 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
/* advance next available entry index of stbl */
++p->header.nextindex;
+
+ return 0;
}
--
2.51.1.dirtyBelow syzbot bug has not been fixed yet. If anyone has time I would greatly appreciate a review of my patch, so it can be moved along. It has been sitting for a few weeks. Thanks, Jori. Apologies for the resend, I messed up the email headers. > Op 29-10-2025 00:23 CET schreef Jori Koolstra <jkoolstra@xs4all.nl>: > > > Syzbot reported a general protection fault in inode_set_ctime_current. > This resulted from the following circumstances: when creating a new file > via dtInsert, BT_GETSEARCH may yield a pointer to a dtroot which is > embedded directly in the jfs_inode_info. When finally dtInsertEntry is > called, if the freelist field or any next field of a slot of the dtpage > is corrupted, this may result in memory corruption of the parent > directory inode. > > In this case the i_sb field was corrupted, which raised the gpf when > in inode_set_ctime_current i_sb was dereferenced to access s_time_gran. > > I tested the patch using the syzbot reproducer and doing some basic > filesystem operations on a fresh jfs fs, such as "cp -r /usr/include/ > /mnt/jfs/" and "rm -r /mnt/jfs/include/n*" > > Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl> > Reported-by: syzbot+cd7590567cc388f064f3@syzkaller.appspotmail.com > Closes: https://syzbot.org/bug?extid=cd7590567cc388f064f3
Below syzbot bug has not been fixed yet. If anyone has time I would greatly appreciate a review of my patch, so it can be moved along. It has been sitting for quite a few weeks. Thanks, Jori. > Op 29-10-2025 00:23 CET schreef Jori Koolstra <jkoolstra@xs4all.nl>: > > > Syzbot reported a general protection fault in inode_set_ctime_current. > This resulted from the following circumstances: when creating a new file > via dtInsert, BT_GETSEARCH may yield a pointer to a dtroot which is > embedded directly in the jfs_inode_info. When finally dtInsertEntry is > called, if the freelist field or any next field of a slot of the dtpage > is corrupted, this may result in memory corruption of the parent > directory inode. > > In this case the i_sb field was corrupted, which raised the gpf when > in inode_set_ctime_current i_sb was dereferenced to access s_time_gran. > > I tested the patch using the syzbot reproducer and doing some basic > filesystem operations on a fresh jfs fs, such as "cp -r /usr/include/ > /mnt/jfs/" and "rm -r /mnt/jfs/include/n*" > > Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl> > Reported-by: syzbot+cd7590567cc388f064f3@syzkaller.appspotmail.com > Closes: https://syzbot.org/bug?extid=cd7590567cc388f064f3
On 12/1/25 7:20AM, Jori Koolstra wrote: > Below syzbot bug has not been fixed yet. If anyone has time I would > greatly appreciate a review of my patch, so it can be moved along. > It has been sitting for quite a few weeks. I've been busy with some other work as well as being out on vacation lately. I have several patches to review, but have not forgotten this. I'll try to get to it later this week. Thanks, Shaggy > > Thanks, > Jori. > >> Op 29-10-2025 00:23 CET schreef Jori Koolstra <jkoolstra@xs4all.nl>: >> >> >> Syzbot reported a general protection fault in inode_set_ctime_current. >> This resulted from the following circumstances: when creating a new file >> via dtInsert, BT_GETSEARCH may yield a pointer to a dtroot which is >> embedded directly in the jfs_inode_info. When finally dtInsertEntry is >> called, if the freelist field or any next field of a slot of the dtpage >> is corrupted, this may result in memory corruption of the parent >> directory inode. >> >> In this case the i_sb field was corrupted, which raised the gpf when >> in inode_set_ctime_current i_sb was dereferenced to access s_time_gran. >> >> I tested the patch using the syzbot reproducer and doing some basic >> filesystem operations on a fresh jfs fs, such as "cp -r /usr/include/ >> /mnt/jfs/" and "rm -r /mnt/jfs/include/n*" >> >> Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl> >> Reported-by: syzbot+cd7590567cc388f064f3@syzkaller.appspotmail.com >> Closes: https://syzbot.org/bug?extid=cd7590567cc388f064f3
Hello David, Thanks for the update. I hope you can get to it soon, but I understand you are busy. I am doing the Linux Kernel Mentorship Program, and trying to get my patches in. Hope you don't mind the occasional reminder. > Op 01-12-2025 23:35 CET schreef Dave Kleikamp <dave.kleikamp@oracle.com>: > > > On 12/1/25 7:20AM, Jori Koolstra wrote: > > Below syzbot bug has not been fixed yet. If anyone has time I would > > greatly appreciate a review of my patch, so it can be moved along. > > It has been sitting for quite a few weeks. > > I've been busy with some other work as well as being out on vacation > lately. I have several patches to review, but have not forgotten this. > I'll try to get to it later this week. > > Thanks, > Shaggy > Thanks, Jori.
© 2016 - 2026 Red Hat, Inc.