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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®