Re: [PATCH] xfs: detect cycles in recovered unlinked inode lists

[Carlos Maiolino]

Please leave the message you're replying to quoted in your email...

On Tue, May 19, 2026 at 08:48:33AM -0400, Michael Bommarito wrote:
> Hi Christoph,
> 
> This research agenda and patch comes from a hardening project
> focused on automount filesystems in major modern distros.
> Maybe the USB stick threat model isn't worth the patch for
> just DoS impact, but that's at least why I thought it worth
> submitting in the first place.

The patch ain't completely invalid, but by the time you've somebody
untrusted with physical access to the system to put a USB stick on,
your security is already gone.
Automounting filesystems (a thing we've been fighting against for
years) just adds on top of it.

> 
> I looked more closely at current xfsprogs for-next
> to answer Darrick's repair question.  Plain xfs_repair refuses
> the reproducer because the log is dirty and needs replay; that
> replay is the mount-time path that hangs on the vulnerable kernel.
> 
> xfs_repair -n diagnoses the AGI unlinked bucket and inode
> next_unlinked damage, and xfs_repair -L clears the bucket /
> next_unlinked state and repairs the image, with the usual log-loss
> caveat.
> 
> I also found a narrower userspace diagnostic issue: xfs_db
> dump_iunlinked follows di_next_unlinked until NULLAGINO and will
> spin on the same self-cycle.  xfs_repair itself does not appear to
> use that unbounded walker in the tested repair path, and xfs_scrub
> userspace is mostly driving the kernel scrub ioctls.
> 
> To be fully safe from automount attacks, I think both sides would
> need to be addressed.
> 
> Your bigger point about regressions and test coverage is still
> valid though.  FWIW, I have been talking with some other fs
> maintainers about adding test/ fuzzing coverage either in-tree
> or external.  I would be happy to help with add XFS coverage
> as part of that project, although I'd defer to your preference
> about where those tests should actually live.

I don't think such tests belongs neither in-tree nor in xfstests, but
this seems a good idea to start a project related to test filesystems
resiliency against those issues. syscaller already does a lot of fuzzing
but mostly random and not containing a bunch of carefully crafted
filesystems to triggers specific issues.

> All that said, just let me know if you still want a v2 based
> on the threat model.

I don't think this is something we want to have without having a
reliable way to test this code to fix a theoretical attack vector, but,
if by any chance it comes to a v2, there are a lot of duplicated code
that should probably belong into its own helper.

Cheers,
Carlos