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

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]

Hi,

Mounting an XFS volume whose log record after the transaction header
carries an operation header with the XLOG_WAS_CONT_TRANS flag panics
the kernel during log recovery - on a stock kernel, no sanitizer
configuration needed:

  BUG: unable to handle page fault for address: fffffffffffffff0
  #PF: supervisor read access in kernel mode
  Oops: Oops: 0000 [#1] SMP KASAN PTI
  RIP: xlog_recover_add_to_cont_trans+0xf9/0x460
   xlog_recovery_process_trans
   xlog_recover_process_ophdr
   xlog_recover_process_data
   xlog_recover_process
   xlog_do_recovery_pass
  Kernel panic - not syncing: Fatal exception

## The gap

xlog_recover_add_to_trans() creates a recover item for the transaction
header via xlog_recover_add_item():

  item = kzalloc_obj(struct xlog_recover_item, ...);
  INIT_LIST_HEAD(&item->ri_list);
  list_add_tail(&item->ri_list, head);

The item has ri_cnt == 0 and ri_buf == NULL - the transaction header
itself is copied into trans->r_theader, not into the item.

If the very next operation header carries XLOG_WAS_CONT_TRANS,
xlog_recovery_process_trans() dispatches to
xlog_recover_add_to_cont_trans(), which takes the tail item and indexes
it without checking that it has any regions buffered
(fs/xfs/xfs_log_recover.c:2144):

  item = list_entry(trans->r_itemq.prev, struct xlog_recover_item, ri_list);
  old_ptr = item->ri_buf[item->ri_cnt-1].iov_base;

ri_buf is NULL and ri_cnt is 0, so the expression reads
NULL[-1] - the faulting address fffffffffffffff0.

Nothing on the path validates the operation-flag sequence against the
item state. The only ri_cnt-related check in the recovery code is an
ASSERT() in xlog_recover_reorder_trans(), which is a no-op on a kernel
without XFS debugging enabled.

Note that the flag's name suggests it belongs to a continuation, but
reaching the crash does not require constructing one: a single
XLOG_WAS_CONT_TRANS operation right after the transaction header is
enough, because the dispatcher never checks that the previous region
had a buffer attached.

## Reproducer shape

The volume is made with a real dirty log (mkfs.xfs, files, sync, crash),
then the first region operation header after the transaction header has
its oh_flags changed from 0x00 to 0x08 (XLOG_WAS_CONT_TRANS), and the
v2 log record CRC is recomputed (328-byte header + h_len payload). The
unmodified dirty-log image recovers and mounts cleanly as a control.

Trigger is mount(2) alone. Reproduced 3/3 with panic_on_oops; the code
in mainline as of 2026-11-06 is identical here.

## Suggested fix

Either bound the item before use in add_to_cont_trans(), or validate
the flag sequence at dispatch time - XLOG_WAS_CONT_TRANS on a
transaction whose tail item has no regions is corruption and should
fail recovery the same way the other -EFSCORRUPTED paths do:

  item = list_entry(trans->r_itemq.prev, struct xlog_recover_item, ri_list);
+ if (!item->ri_cnt) {
+         xfs_warn(log->l_mp, "%s: continuation with no previous region", __func__);
+         return -EFSCORRUPTED;
+ }

The reproducer (image builder that locates the record/op, flips the
flag and recomputes the CRC, plus a ready-made image and serial log) is
available on request.

Thanks,
Guikun Yang