From: CJ <firefly0158@163.com>
To: mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com
Cc: ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
syzbot+09184149c7c0d9e6f83a@syzkaller.appspotmail.com
Subject: [BUG] ocfs2: kernel BUG in ocfs2_populate_inode still reproducible on v7.3-rc1
Date: Mon, 14 Sep 2026 13:55:06 +0800 (CST) [thread overview]
Message-ID: <c4e7b8a.4e41.1a09e7bc2a9.Coremail.firefly0158@163.com> (raw)
Hi,
I am reporting a kernel BUG in ocfs2's inode population path, triggered by a
syzkaller reproducer that mounts a crafted ocfs2 image. The issue is
reproducible with HEAD commit cee9395acd8043be0644b25c34bfa86623f2b935
(v7.3-rc1, Linux 7.3.0-rc1).
The reproducer mounts a small ocfs2 filesystem image on a loop device. The
image carries a dinode with the OCFS2_SUPER_BLOCK_FL flag set that still passes
the existing inode-block validator, so the mount path accepts it as an ordinary
dinode. During superblock setup the mount initializes the global system
inodes, reads that dinode through ocfs2_read_locked_inode and hands it to
ocfs2_populate_inode.
ocfs2_populate_inode then reaches the branch that handles a dinode flagged as a
superblock and calls BUG() unconditionally. The target console shows
"kernel BUG at fs/ocfs2/inode.c:448!", an invalid-opcode Oops, and RIP in
ocfs2_populate_inode. The path is the mount-time system-inode initialization:
ocfs2_read_locked_inode -> ocfs2_iget -> ocfs2_get_system_file_inode ->
ocfs2_initialize_super -> ocfs2_fill_super -> mount.
One possible cause is that nothing on the read path rejects a dinode carrying
OCFS2_SUPER_BLOCK_FL before it reaches ocfs2_populate_inode. The comment at the
BUG() site notes that read_inode cannot handle superblocks, but
ocfs2_validate_inode_block only inspects i_flags for OCFS2_VALID_FL; it checks
the ECC, the dinode signature, i_blkno, i_links_count, i_mode and
i_fs_generation, and never looks at OCFS2_SUPER_BLOCK_FL. A crafted image that
sets VALID_FL together with SUPER_BLOCK_FL therefore passes validation. This
looks like a case where the invariant the BUG() asserts is not enforced on the
on-disk-input path. I note that recent work in this file
(bb88131c9831, b2d31acbd3b1, 8914a3330b72) tightened adjacent dinode validation
but does not cover this flag.
This appears to be a recurrence of the syzbot issue whose external id is
09184149c7c0d9e6f83a (title "kernel BUG in ocfs2_populate_inode"). It remains
reproducible on v7.3-rc1. I am aware that two patches were proposed earlier
(one replacing the BUG() with ocfs2_error() plus make_bad_inode(), one rejecting
the flag in ocfs2_validate_inode_block) and that a review argued the existing
BUG() is acceptable for metadata corruption. I am reporting the reproduction
only; if the current behaviour is considered correct, please disregard this.
Reproducer:
syz reproducer: https://pastebin.com/raw/C3BdtqfE
console output: https://pastebin.com/raw/Ld7dqEc4
kernel config: https://pastebin.com/raw/SGA1HK95
Kernel:
HEAD commit: cee9395acd8043be0644b25c34bfa86623f2b935
git tree: upstream (linux.git), tested through the v7.3-rc1 annotated tag object
e5e04726cdd043e309677071ab1b65a4b18f422b
kernel version: 7.3.0-rc1 #1 PREEMPT(full)
tested tag: v7.3-rc1 (Linux 7.3-rc1, 2026-08-30)
Let me know if you need more details or testing.
Best regards,
Changjian
reply other threads:[~2026-09-14 5:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=c4e7b8a.4e41.1a09e7bc2a9.Coremail.firefly0158@163.com \
--to=firefly0158@163.com \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=syzbot+09184149c7c0d9e6f83a@syzkaller.appspotmail.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.