XFS log recovery bugs can panic Linux on mount

Mounting an XFS filesystem whose dirty log has been lightly altered can crash the Linux kernel during recovery. Guikun Yang reported nine distinct flaws in the mount-time log replay path, spanning null-pointer dereferences, slab out-of-bounds reads, and geometry fields taken from the log without the checks used on a normal superblock read.

The failures need no sanitizer build and no exotic setup. A volume that began as a real crash-dirty log, with a few operation-header or buffer-item fields changed and the log CRC recomputed, is enough. Unmodified images recover and mount; the altered ones hit the faults consistently.

One gap is pure control-flow trust. After a transaction header creates a recover item with no buffered regions, an immediately following operation marked XLOG_WAS_CONT_TRANS indexes that item as if a prior region existed, reading through a null buffer pointer and panicking. Nothing on the path checks that the flag sequence matches item state; the only related guard is an ASSERT that vanishes on production kernels.

A second class installs the logged primary superblock into the in-core superblock with almost no validation. Only AG and realtime group counts are checked against shrinkage. Fields such as inodes-per-block log are then used by AG sizing code and can trigger shift-out-of-bounds panics. The ordinary mount read path runs full superblock verification; recovery bypasses it for the same on-disk structure.

Inode and buffer item replay add further asymmetries. Logged inode buffer lengths are passed straight into reads without requiring whole filesystem blocks, so verifiers that round length up and walk inode slots read past the allocated slab. Format size is taken from a region that may be shorter than the format header itself. Bitmap-driven recovery of inode and regular buffers advances a region index once per set-bit run without tying the map to how many regions the item actually carried, again walking off the end of the region array once ASSERTs are compiled out.

In each case the log is a weaker trust boundary than the corresponding non-recovery path. An attacker who can present a malicious XFS image (removable media, imported volume, or similar) can force a host panic at mount rather than a clean rejection of corrupt metadata. Fixes were not yet described in the initial reports.