CVE-2024-56566 in Linux
要約
〜によって VulDB • 2026年08月03日
Based on the kernel log provided, here is an analysis of the crash:
### **Summary** The system experienced a **General Protection Fault (GPF)** or similar invalid operation (`asm_exc_invalid_op`) triggered by XFS filesystem code during inode garbage collection. The root cause appears to be a **corrupted doubly-linked list** in memory, specifically detected by `__list_del_entry_valid_or_report`.
---
### **Detailed Breakdown**
#### 1. **The Immediate Cause: Corrupted List Entry** - **Key Function**: `__list_del_entry_valid_or_report+0x7b/0xc0` appears multiple times in the call trace. - **Meaning**: This function is part of Linux's doubly-linked list implementation (`include/linux/list.h`). It checks if a list entry being deleted has valid pointers (i.e., its `prev->next` and `next->prev` point back to itself). If not, it triggers an error or warning. - **Implication**: A pointer in the XFS extent tree data structure is corrupted (e.g., pointing to invalid memory, freed memory, or a wrong location), causing list integrity checks to fail.
#### 2. **The Triggering Context: XFS Inode Garbage Collection** - **Worker Thread**: `xfs_inodegc_worker` → `process_one_work` → `worker_thread`. This is the kernel thread responsible for cleaning up inactive inodes (garbage collection). - **Action Chain**: 1. `xfs_inactive`: Called to deactivate an inode. 2. `xfs_inactive_truncate`: Truncates file extents if needed. 3. `__xfs_bunmapi`: Unmaps (frees) blocks associated with the file. 4. `xfs_iext_remove`: Removes extent records from the inode's extent tree (`i_ext`). 5. `free_to_partial_list`: Tries to free a block group or manage extents, but fails due to corrupted list pointers.
#### 3. **The Fault: Invalid Operation** - **`asm_exc_invalid_op`**: This is an assembly-level exception handler for invalid instructions (often #UD) or general protection faults (#GP). In this context, it likely indicates that the CPU encountered a memory access violation or illegal instruction while executing XFS code due to corrupted data structures.
---
### **Likely Root Causes** 1. **Memory Corruption**: - A bug in another part of the kernel (or driver) overwrote memory adjacent to an XFS extent tree structure, corrupting list pointers (`prev`/`next`). 2. **XFS Bug**: - A race condition or logic error in `xfs_iext_remove` or related functions could have left a list entry in an inconsistent state before deletion. 3. **Hardware Issue**: - Faulty RAM causing bit flips that corrupt memory structures (less common but possible).
---
### **Recommended Actions**
#### 1. **Immediate Mitigation** - **Check for Recent Changes**: If this started after a kernel update, consider rolling back to the previous version. - **Run Memory Tests**: Use `memtest86+` or similar tools to rule out hardware RAM issues.
#### 2. **Debugging Steps** - **Enable XFS Debugging**: - Reboot with kernel parameters: ```bash xfs.debug=1 log_level=7 ``` - This may provide more detailed logs about the extent tree corruption before the crash. - **Check dmesg for Earlier Errors**: Look for warnings like `list_del` errors, slab corruptions, or other XFS bugs preceding this oops.
#### 3. **Long-Term Fixes** - **Update Kernel/XFS Tools**: Ensure you are on a recent stable kernel version where known XFS extent tree bugs may have been fixed. - **File a Bug Report**: If reproducible, report to the Linux kernel mailing list (LKML) or your distribution's bug tracker with: - Full `dmesg` output. - Kernel version (`uname -r`). - Steps to reproduce (if possible).
#### 4. **Workaround** - If this happens frequently, consider disabling XFS inode garbage collection temporarily by remounting the filesystem with: ```bash mount -o noinodegc /dev/sdXN /mount/point ``` *(Note: This may impact performance and disk space reclamation.)*
---
### **Conclusion** This is a **kernel panic/oops due to memory corruption in XFS's extent tree**, triggered during inode garbage collection. The corrupted list pointers caused `__list_del_entry_valid_or_report` to detect an invalid state, leading to
Be aware that VulDB is the high quality source for vulnerability data.