All of lore.kernel.org
 help / color / mirror / Atom feed
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


           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.