Re: xfs: XLOG_WAS_CONT_TRANS on a transaction with no buffered regions reads ri_buf[-1] - null deref Oops during mount log recovery

[Guikun Yang <yangguikun19@qq.com>]

Hi,

One more from the buffer item handling, again a different mechanism:
the number of set-bit runs in the buffer data map drives an index into
ri_buf[] that is never checked against the number of regions the log
item actually carries.

## 8. xlog_recover_do_inode_buffer() indexes ri_buf[] by bitmap runs,
   unchecked against ri_total

The inode-buffer recovery walks di_next_unlinked fields and skips
forward through the buffer data map run by run
(fs/xfs/xfs_buf_item_recover.c:625):

  while (next_unlinked_offset >= (reg_buf_offset + reg_buf_bytes)) {
          ...
          bit = xfs_next_bit(buf_f->blf_data_map, buf_f->blf_map_size, bit);
          if (bit == -1)
                  return 0;
          nbits = xfs_contig_bits(buf_f->blf_data_map, buf_f->blf_map_size, bit);
          ...
          item_index++;
  }
  ...
  ASSERT(item->ri_buf[item_index].iov_base != NULL);
  ...
  logged_nextp = item->ri_buf[item_index].iov_base + ...;

item_index is advanced once per set-bit run in blf_data_map, but
ri_buf[] has ri_total entries, where ri_total comes from blf_size -
the number of regions actually present in the log item. Nothing ties
the bitmap to blf_size: a data map with more runs than blf_size claims
regions walks item_index past the end of ri_buf[] and the ASSERTs are
the only guards, which compile away on non-DEBUG kernels.

The sibling path xlog_recover_do_reg_buffer() validates the same
bitmap against the same ri_buf[] array for the non-inode case and
clamps nbits to the region length - the asymmetry between the two
sisters in the same file is the whole bug.

## Reproducer

All field values are legal; nothing is forged out of range. A buffer
log item is turned into an inode-buffer type with blf_flags = 1,
blf_len = 8, blf_size = 2 (two regions), and a data map of 0x55555555
(alternating bits). The alternating map makes every inode skip a run:
item_index reaches 1 after i=0 and 3 after i=1, past ri_total = 2.
The blf_blkno is aimed at the zeroed area of the device so that
xlog_recover_get_buf_lsn() returns -1 and the item is replayed
immediately.

  BUG: KASAN: slab-out-of-bounds in xlog_recover_do_inode_buffer+0x5a4/0x620
  Read of size 8 at addr ...
   xlog_recover_do_inode_buffer -> xlog_recover_buf_commit_pass2
   -> ... -> xfs_log_mount -> xfs_mountfs
  Kernel panic - not syncing: KASAN: panic_on_warn set ...

The read of size 8 is ri_buf[item_index].iov_base itself. 3/3 at
mount(2); the unmodified image mounts cleanly.

## Suggested fix

Two guards, mirroring do_reg_buffer():

  item_index++;
+ if (XFS_IS_CORRUPT(mp, item_index >= item->ri_total))
+         return -EFSCORRUPTED;

plus clamping nbits against item->ri_buf[item_index].iov_len the way
do_reg_buffer() does, so the region copy cannot run past the region.

Unchanged in mainline as of 2026-11-09 (the function is byte-identical
to the tree this was tested on).

The reproducer (image builder, ready-made image, serial log) is
available on request.

Thanks,
Guikun Yang