CVE-2024-55641

In the Linux kernel, the following vulnerability has been resolved:

xfs: unlock inodes when erroring out of xfstransalloc_dir

Debugging a filesystem patch with generic/475 caused the system to hang after observing the following sequences in dmesg:

XFS (dm-0): metadata I/O error in "xfsimaptobp+0x61/0xe0 [xfs]" at daddr 0x491520 len 32 error 5 XFS (dm-0): metadata I/O error in "xfsbtreereadbufblock+0xba/0x160 [xfs]" at daddr 0x3445608 len 8 error 5 XFS (dm-0): metadata I/O error in "xfsimaptobp+0x61/0xe0 [xfs]" at daddr 0x138e1c0 len 32 error 5 XFS (dm-0): log I/O error -5 XFS (dm-0): Metadata I/O Error (0x1) detected at xfstransreadbufmap+0x1ea/0x4b0 [xfs] (fs/xfs/xfstransbuf.c:311). Shutting down filesystem. XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): Internal error dqp->qino.reserved < dqp->qino.count at line 869 of file fs/xfs/xfstransdquot.c. Caller xfstransdqresv+0x236/0x440 [xfs] XFS (dm-0): Corruption detected. Unmount and run xfs_repair XFS (dm-0): Unmounting Filesystem be6bcbcc-9921-4deb-8d16-7cc94e335fa7

The system is stuck in unmount trying to lock a couple of inodes so that they can be purged. The dquot corruption notice above is a clue to what happened -- a link() call tried to set up a transaction to link a child into a directory. Quota reservation for the transaction failed after IO errors shut down the filesystem, but then we forgot to unlock the inodes on our way out. Fix that.