CVE-2025-38713 in Linux
Resumen
por VulDB • 2026-06-30
Based on the kernel log provided, this is a **KASAN (Kernel Address Sanitizer)** report indicating an out-of-bounds memory access in the `hfsplus` filesystem driver.
### Summary of the Issue * **Error Type:** Out-of-bounds read/write (likely write or invalid access). * **Location:** The buggy address is located **0 bytes to the right** of a previously allocated region. This means it's an **off-by-one error** at the very end of a buffer, or potentially accessing just past the boundary if alignment/padding was miscalculated. * **Affected Cache:** `kmalloc-2k` (size 2048 bytes). * **Allocated Size:** The object allocated was only **1036 bytes**. * **Buggy Address Location:** `ffff88802592f000 + 1036 = ffff88802592f40c`. The access happened at or beyond this address.
### Call Chain Analysis (Who allocated it?) The allocation stack trace shows: ```text hfsplus_find_init+0x95/0x1f0 <-- Allocation happens here via kmalloc/kzalloc hfsplus_readdir+0x220/0xfc0 <-- Called during directory reading (getdents64) iterate_dir+... __x64_sys_getdents64+... <-- User-space syscall: readdir/getdents64 ```
This means the bug occurs when a user process tries to read a directory on an HFS+ filesystem, triggering `hfsplus_readdir`, which calls `hfsplus_find_init` to allocate some internal structure (likely for searching or caching catalog records). The allocated buffer is too small, and later code writes/reads past its end.
### Likely Root Cause In the Linux kernel's `hfsplus` driver: 1. **Buffer Size Miscalculation:** The size passed to `kmalloc()` in `hfsplus_find_init` might be computed incorrectly (e.g., missing padding, wrong field offset calculation). 2. **Off-by-One Error:** A loop or copy operation assumes a buffer of one more byte than allocated. 3. **Struct Padding/Alignment Issue:** If the code uses `sizeof(struct)` but expects packed layout without proper alignment handling, it might under-allocate.
### How to Fix / Investigate Further
#### 1. Locate the Code Look at: ```bash fs/hfsplus/btree.c # hfsplus_find_init is likely here fs/hfsplus/dir.c # hfsplus_readdir calls find_init ```
Specifically, examine `hfsplus_find_init()` around offset `0x95`. Find the `kmalloc` or `kzalloc` call. It probably looks something like: ```c struct *info = kmalloc(size, GFP_KERNEL); ``` Check how `size` is calculated.
#### 2. Check for Common Pitfalls in HFS+ Code HFS+ uses B-trees and catalog records that have variable sizes or specific alignment requirements. A common bug pattern: - Allocating based on a header size but not accounting for the full record length. - Using `sizeof(struct hfsplus_cat_record)` when only part of it is needed, then accessing beyond.
#### 3. Reproduce and Debug Since this requires KASAN enabled (usually via kernel config or boot parameter), you can: - Enable KASAN in your test environment. - Trigger the bug by listing a directory on an HFS+ filesystem that contains certain file types/names. - Use `gdb` attached to the kernel with vmlinux symbols to inspect the exact instruction causing the fault and the values of registers at crash time (though you already have KASAN’s detailed report).
#### 4. Patch Example Hypothesis If the allocation is: ```c info = kmalloc(sizeof(struct hfsplus_btree_search), GFP_KERNEL); ``` But later code accesses `info->record` which expects more space, or if it allocates based on a variable length field that was misread, you need to ensure the size includes all necessary fields.
For example, if it’s allocating for a catalog record: ```c // Wrong: might miss padding or full extent count size = sizeof(struct hfsplus_cat_entry) + name_len;
// Correct: include proper alignment and any additional metadata expected by subsequent code size = ALIGN(sizeof(struct hfsplus_cat_entry), 4) + name_len + extra_padding_needed_by_find_init_logic; ```
### Conclusion This is a **memory corruption bug** in the `hfsplus` filesystem driver due to
If you want to get best quality of vulnerability data, you may have to visit VulDB.