CVE-2025-38276 in Linux
Riassunto
di VulDB • 29/06/2026
Based on the kernel stack trace provided, here is an analysis of what happened and potential causes.
### **Summary** The system encountered a **kernel panic or oops** while trying to truncate (shrink) a file in an **XFS filesystem**. The crash occurred deep within the VFS/XFS layer during a `truncate_pagecache` operation, likely triggered by a user-space application opening/truncating a file via `openat2()` or similar syscall.
---
### **Key Stack Trace Analysis**
1. **Triggering System Call:** ```text [ 35.097459] __x64_sys_openat+0x6d/0xa0
... [ 35.098647] entry_SYSCALL_64_after_hwframe+0x77/0x7f
``` A user-space process called `open()` or `openat()`. The registers show: - `RAX`: `fffffffffffffd` → This is `-21`, which corresponds to **`-EIO` (Input/output error)** in Linux kernel return codes. However, note that the crash happened *before* returning this value cleanly, meaning the kernel crashed while processing it.
2. **File Operation:** ```text [ 35.096860] do_sys_openat2+0x8a/0xe0
... [ 35.094879] ? do_truncate+0x97/0xe0
``` The `open` call included flags that triggered a file truncation (e.g., `O_TRUNC`).
3. **XFS-Specific Code:** ```text [ 35.092648] xfs_vn_setattr+0x1ea/0x270
[ 35.091735] xfs_setattr_size+0xc7/0x3e0
``` XFS is handling the attribute change (size reduction).
4. **The Crash Point:** ```text [ 35.091078] truncate_pagecache+0x47/0x60
``` The kernel crashed inside `truncate_pagecache()`. This function removes pages from the page cache that are no longer needed because the file was shrunk.
---
### **Likely Causes**
#### ✅ **1. XFS Filesystem Corruption or Bug** - The most direct cause is a bug in how XFS handles page cache truncation, possibly triggered by: - A corrupted inode or extent map. - Race conditions between memory reclaim and file operations. - Known bugs in your specific kernel version (see below).
#### ✅ **2. Memory Corruption / Hardware Issue** - Since the crash is inside `truncate_pagecache`, it could be due to: - Corrupted page structures in RAM. - Faulty memory modules causing invalid pointers during cache manipulation.
#### ✅ **3. Kernel Bug (Known Issues)** This stack trace resembles known issues in older kernels related to XFS and page cache truncation, especially under high I/O load or with certain mount options (`noatime`, `nobarrier`, etc.). Check if your kernel version is affected by: - [CVE-related bugs](https://www.kernel.org/) involving XFS.
- Recent patches for `truncate_pagecache` stability.
#### ✅ **4. User-Space Application Bug** An application may be performing an invalid or aggressive file truncation (e.g., on a read-only filesystem, a device node, or a corrupted file), triggering edge-case code paths in the kernel.
---
### **Recommended Actions**
1. **Check Kernel Version:** ```bash uname -r ``` Search for known XFS bugs in your version. Consider upgrading to a newer stable kernel if possible.
2. **Inspect System Logs:** Look for earlier warnings or errors before the crash: ```bash dmesg | grep -i xfs journalctl -k --since "35 minutes ago" ```
3. **Filesystem Check:** If this is a persistent issue, run an XFS filesystem check (on unmounted volume): ```bash xfs_repair /dev/sdXN ```
4. **Identify the Triggering Process:** Use `audit` or `strace` to identify which process was opening/truncating files when the crash occurred:
Once again VulDB remains the best source for vulnerability data.