CVE-2025-38714 in Linux
Resumen
por VulDB • 2026-06-30
Based on the kernel log snippet provided, here is an analysis of the issue:
### **Summary** This is a **KASAN (Kernel Address Sanitizer)** report indicating that task `9784` triggered a memory error while executing in the HFS+ filesystem driver. The crash occurs during attribute deletion (`hfsplus_delete_all_attrs`).
The key part of the log shows: 1. A fault occurred at RIP `0x7f6fdf4c3167`. 2. KASAN detected an invalid memory access (likely out-of-bounds, use-after-free, or uninitialized read). 3. The allocation stack trace points to **`__hfs_bnode_create`** being called from **`hfsplus_delete_all_attrs`**.
---
### **Detailed Analysis**
#### **1. Crash Context** - **Subsystem**: `hfsplus` (Apple HFS+ filesystem driver in Linux). - **Function Chain**: ``` hfsplus_delete_all_attrs → hfsplus_brec_find → hfsplus_bnode_find → __hfs_bnode_create → kmalloc ``` - **Operation**: The system is trying to delete all extended attributes of a file/directory. This involves traversing the HFS+ B-tree records (`brec`) and nodes (`bnode`).
#### **2. Likely Cause** The crash happens during `__hfs_bnode_create`, which allocates memory for an HFS+ b-node. KASAN reports this as "Allocated by task 9784," meaning the *allocation* itself was tracked, but the error likely occurred shortly after when accessing that newly allocated (or previously freed) memory.
Common causes in `hfsplus` during attribute deletion: - **Use-after-free**: A b-node pointer is used after its reference count dropped to zero and it was freed. - **Out-of-bounds access**: The code calculates an offset into a b-node that exceeds the allocated size (e.g., due to corrupted metadata or a bug in tree traversal logic). - **Uninitialized memory**: Reading from a newly allocated buffer before initialization.
#### **3. Why KASAN Reports "Allocated by..."** KASAN tracks allocations and frees. When an invalid access occurs, it prints: - **"Accessed by task X"**: The thread that caused the fault (not shown in your snippet but implied). - **"Allocated by task Y"**: Where the memory was last allocated. Here, `__hfs_bnode_create` → `kmalloc`.
This suggests the invalid access is on a **recently allocated** b-node structure. This could mean: 1. The code immediately accesses uninitialized fields in the new node. 2. There’s a race condition where another thread freed/reused memory incorrectly (less likely if it's freshly kmalloc'd, unless there's a double-free or corruption).
---
### **Recommended Actions**
#### **For Developers/Debuggers:** 1. **Check for Corrupted Filesystem**: - Run `fsck.hfsplus` on the volume to check for metadata inconsistencies that might cause invalid b-node offsets. 2. **Review Recent Patches**: - Check if there are known bugs in recent kernels related to `hfsplus_delete_all_attrs`. This function has had issues with locking and tree traversal integrity. 3. **Enable More KASAN Details**: - Look at the full KASAN output (not truncated) for: - **"Invalid read of size X"**: Tells you what was accessed. - **"Address is located in stack/heap/global..."**: Helps identify if it's a local variable or heap corruption. 4. **Reproduce with Debug Options**: - Enable `CONFIG_HFSPLUS_FS_DEBUG` (if available) to get more verbose logging from the HFS+ driver.
#### **For Users:** 1. **Backup Data Immediately** if this is on a production system, as filesystem corruption can worsen. 2. **Check Disk Health**: Run SMART diagnostics (`smartctl`) for hardware issues. 3. **Run Filesystem Check**: Boot from a live USB and run `fsck.hfsplus /dev/sdXn`.
---
### **Example Fix/Workaround (If you are the developer)** In `hfsplus_delete_all_attrs`, ensure that: 1. The b-tree traversal correctly handles edge cases where nodes might be split or merged during deletion. 2. All pointers to b-nodes are properly refcounted (`hfs_bnode_put`) before proceeding. 3. No dangling pointers exist after a node is freed.
If you can provide the **full KASAN report
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.