CVE-2024-55641

What it actually does

Failure to release inode locks on error paths inside xfs_trans_alloc_dir leaves inodes pinned after quota reservation or I/O failures, causing deadlock during subsequent unmount and purge operations.

Why it matters to the business

Filesystem becomes inaccessible after metadata errors, forcing administrators to unmount, run repair, and accept downtime or potential data inconsistency on production storage volumes.

How an attack unfolds

An attacker or workload triggers repeated metadata I/O errors or quota reservation failures during directory link operations; the error exit from xfs_trans_alloc_dir omits inode unlock, so later unmount attempts block indefinitely waiting for those locks.

How to fix it

Apply the upstream fix that adds the missing inode unlock on the error exit of xfs_trans_alloc_dir; reboot into a kernel containing the corrected XFS code. For the listed Ubuntu packages, install the indicated gdb, libiberty, and valgrind updates if they carry backported changes.

How to confirm the fix worked

Confirm the presence of the unlock call on all error returns from xfs_trans_alloc_dir in the running kernel source; attempt to reproduce the generic/475 test sequence and verify the filesystem unmounts cleanly without deadlock.

Typical attack path

1. Induce XFS metadata I/O errors via underlying storage faults or crafted filesystem images
2. Perform directory operations such as link() that allocate a transaction and reserve quota
3. Hit the error path in xfs_trans_alloc_dir after shutdown has been initiated
4. Observe dquot corruption warnings followed by hang on inode lock during unmount

How to detect it

Search kernel logs for sequences containing "xfs_trans_alloc_dir", "dqp->q_ino.reserved", "Internal error", and "Unmounting Filesystem" followed by prolonged unmount hangs; correlate with XFS shutdown messages.

What your security team should do

• Prioritize kernel updates containing the XFS inode unlock fix on all systems using XFS
• Monitor storage health to reduce incidence of the I/O errors that trigger the buggy path
• Test unmount and repair procedures in a lab environment before applying to production