mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* f2fs: orphan entry pointing at an inode with no NAT entry triggers f2fs_bug_on() in recover_orphan_inode() - kernel BUG at mount with CONFIG_F2FS_CHECK_FS
@ 2026-11-03  8:00 Guikun Yang
  2026-11-05  3:44 ` [PATCH] f2fs: don't BUG_ON a missing orphan inode at mount Zhan Xusheng
  0 siblings, 1 reply; 2+ messages in thread
From: Guikun Yang @ 2026-11-03  8:00 UTC (permalink / raw)
  To: Jaegeuk Kim; +Cc: Chao Yu, linux-f2fs-devel, linux-kernel

Hi,

Mounting a crafted f2fs image ends in a kernel BUG during orphan inode
recovery, before any syscall beyond mount():

  kernel BUG at fs/f2fs/checkpoint.c:988!
  Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
  RIP: 0010:f2fs_recover_orphan_inodes+0xa1c/0xcb0
  Kernel panic - not syncing: Fatal exception

The BUG is in recover_orphan_inode() (fs/f2fs/checkpoint.c):

  inode = f2fs_iget_retry(sbi->sb, ino);
  if (IS_ERR(inode)) {
          /*
           * there should be a bug that we can't find the entry
           * to orphan inode.
           */
          f2fs_bug_on(sbi, PTR_ERR(inode) == -ENOENT);
          return PTR_ERR(inode);
  }

The comment assumes that reaching this branch means a kernel bug, but
the ino values come straight from the on-disk orphan area: the only
validation before the loop is an upper bound on entry_count, and the
ino[] array entries are never checked for existence. f2fs_iget()
resolves the ino through the NAT, and a NAT entry whose blk_addr is
NULL_ADDR makes it return -ENOENT (fs/f2fs/node.c). So an orphan entry
whose ino has no NAT entry - or has one freed to NULL_ADDR - walks
straight into the f2fs_bug_on() with no way for the mount to recover.

## The two configurations behave differently

Under CONFIG_F2FS_CHECK_FS this is BUG_ON, fatal at mount. Without it,
f2fs_bug_on() degrades to WARN_ON(1) + SBI_NEED_FSCK and recovery just
returns the error; the mount continues and the orphan is dropped after
"recover_orphan_inode: orphan failed (ino=%x), run fsck to fix." - the
orphan cleanup silently does not happen. The missing existence check
is the same in both configurations; only the reaction differs, and
neither reaction matches what the on-disk state can legitimately
contain after a crash on a fuzzed or corrupted image.

## Reproducer shape

The clean way to build it is to let f2fs write the orphan state
itself: mount, create a file, unlink() with the fd still open, sync()
to get a checkpoint with CP_ORPHAN_PRESENT_FLAG, then crash (sysrq-c).
That produces a self-consistent checkpoint with a real orphan area
(one block, entry_count 1, ino[0] = the unlinked file's ino). Then
only ino[0] is changed to an ino with no NAT entry, and the checkpoint
version is bumped with both checksums recomputed. Four payload bytes
plus version/checksum maintenance, nothing else.

Forging the orphan area layout by hand instead (e.g. rewriting
cp_pack_start_sum to grow the orphan region over the summary blocks)
breaks SIT/NAT journal lookup and the mount aborts before orphan
recovery - the self-written orphan state is what makes the target
reachable.

The reproducer (image builder, ready-made image, crash log) is
available on request. Tested on 7.3.0 with CONFIG_F2FS_CHECK_FS=y,
deterministic 3/3; the f2fs_bug_on() and the missing existence check
are unchanged in current mainline.

Thanks,
Guikun Yang


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-11-05  3:44 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-03  8:00 f2fs: orphan entry pointing at an inode with no NAT entry triggers f2fs_bug_on() in recover_orphan_inode() - kernel BUG at mount with CONFIG_F2FS_CHECK_FS Guikun Yang
2026-11-05  3:44 ` [PATCH] f2fs: don't BUG_ON a missing orphan inode at mount Zhan Xusheng

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®