From: Wang Yibo <szwyb123@gmail.com>
To: Dave Kleikamp <shaggy@kernel.org>
Cc: jfs-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
syzbot+b547ffac63b636628299@syzkaller.appspotmail.com
Subject: Re: [PATCH] jfs: fix out-of-bounds write in add_missing_indices()
Date: Wed, 28 Oct 2026 09:49:05 -0700 (PDT) [thread overview]
Message-ID: <6ae22781.b5b34ff4.243b64.342c@mx.google.com> (raw)
In-Reply-To: <20261028163000.30-1-szwyb123@gmail.com>
While looking at the syzbot report this patch was written for, I found
two more open reports that look like the same bug:
general protection fault in smack_inode_getattr
https://syzkaller.appspot.com/bug?extid=ce678add490179a73d5a
general protection fault in smack_inode_permission
https://syzkaller.appspot.com/bug?extid=fc1d5d9a7ebabbc27458
The second one is still being hit in the current tree, and its console
output has the jfs_readdir() "Dtree error" lines for ino 2 right before
the fault. Both reports die in smk_of_inode() on a crafted
inode->i_security, and both show the same damage: only the upper 32 bits
of the pointer were replaced, by 0x0000000c, so the low half of the
original pointer is still there.
That is one 4-byte store at i_security + 4. For the inline dtree root
the slot entries are 32 bytes with the index field at offset 28, so with
_dtroot at 728 and the embedded inode at 1048 in struct jfs_inode_info, a
write to slot[11].index lands on i_security + 4, and the value stored
there is the directory's next_index, 12 in both reports. The only code
that stores next_index through an unchecked slot index is
add_missing_indices(), when a corrupted stbl[] entry points past the nine
slots the root page has.
I checked this on a SMACK enabled build with the reproducer from the
first report: without the fix it dies in smack_inode_permission from
ksys_umount() with i_security = 0x0000000c27a22900, the same damage as
the two reports above; with the patch the entry is rejected with -EIO and
the directory scan finishes.
So one fix should cover all three reports. I will add the Closes: tags
for them, and Cc the matching syzbot addresses, in v2 once this version
has been reviewed.
Thanks,
Wang Yibo
parent reply other threads:[~2026-10-28 16:49 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20261028163000.30-1-szwyb123@gmail.com>]
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=6ae22781.b5b34ff4.243b64.342c@mx.google.com \
--to=szwyb123@gmail.com \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=shaggy@kernel.org \
--cc=syzbot+b547ffac63b636628299@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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.