Re: [Bug report] xfs: unvalidated ilf_boffset in an inode log item reaches an out-of-bounds read during log recovery

[Guikun Yang <yangguikun19@qq.com>]

Hi,

Following up on this report from October 31 with a re-check against
current mainline (2026-11-08) and a smaller reproducer.

## Current state

xfs_buf_offset() is still a raw pointer add:

  return bp->b_addr + offset;

and ilf_boffset is still used through it exactly once in the tree -
the bare call in xlog_recover_inode_commit_pass2()
(fs/xfs/xfs_inode_item_recover.c):

  dip = xfs_buf_offset(bp, in_f->ilf_boffset);
  if (XFS_IS_CORRUPT(mp, !xfs_verify_magic16(bp, dip->di_magic)))

Nothing bounds ilf_boffset against the buffer that ilf_len bought.
The xfs_verify_magic16() comparison cannot help - it inspects a value
that has already been read out of bounds.

For what it is worth, the inode-item fork regions in this same
function gained bounds in 9232301894 ("xfs: bound inode fork length
against the fork size during log recovery", 2026-09-23), but the
record carries more fields than that fix covered: the buffer length
(ilf_len) and the buffer offset (ilf_boffset) are both still trusted
as-is.

## Smaller reproducer

The original report used a three-step image construction. The same
crash now reproduces with five bytes changed on a real dirty-log
image: ilf_boffset from 0 to 16384 (= BBTOB(ilf_len)) plus the four
CRC bytes of the log record. The unmodified image recovers and mounts
cleanly; the modified one hits

  BUG: KASAN: use-after-free in xlog_recover_inode_commit_pass2+...
  ...
   xlog_recover_inode_commit_pass2 -> ... -> xfs_log_recover -> mount

3/3 at mount(2), with panic_on_warn=1.

The reproducer (log scanner, image builder, ready-made image, serial
log) is available on request. Happy to test a patch - including one
revived from the October RFC series if that is the preferred route.

Thanks,
Guikun Yang