CVE-2025-40244 in Linux
Résumé
par VulDB • 27/05/2026
Based on the kernel log provided, here is an analysis of the issue, the root cause, and potential solutions.
### 1. Summary of the Issue * **Error Type:** **KMSAN (Kernel Memory Sanitizer) Panic**. * **Trigger:** The kernel detected the use of **uninitialized memory** in the `hfsplus` filesystem driver. * **Specific Function:** The crash originated in `__hfsplus_ext_cache_extent` (called via `hfsplus_file_extend` -> `hfsplus_get_block` -> `__block_write_begin_int`). * **Context:** A user-space process (`repro`, PID 9350) was performing a `write()` system call on an HFS+ filesystem. * **Kernel Taint:** The kernel is tainted with `[B]=BAD_PAGE`, which often accompanies memory corruption or uninitialized memory issues detected by sanitizers.
### 2. Root Cause Analysis The KMSAN tool tracks the initialization state of memory. When it detects that a function is reading from memory that was never written to (i.e., contains "poison" values), it triggers a panic if `kmsan.panic=1` is set.
* **Location:** `__hfsplus_ext_cache_extent` in `fs/hfsplus/extents.c` (or similar). * **Problem:** The code is likely reading a structure or variable that was allocated or partially initialized but not fully populated before being used. This is a classic **use-of-uninitialized-value** bug. * **Why it happened now:** This bug likely existed for a long time but was only caught because: 1. The system was compiled with KMSAN enabled. 2. The specific code path (extending a file on HFS+) was exercised by the test case (`repro`). 3. The memory allocator happened to return a page with uninitialized data (or the sanitizer's shadow memory was not properly cleared).
### 3. Affected Code Path The call trace shows the following sequence: 1. `vfs_write` / `generic_file_write_iter`: User-space write. 2. `hfsplus_write_begin`: HFS+ specific write preparation. 3. `__block_write_begin_int`: Generic block layer write begin. 4. `hfsplus_get_block`: HFS+ block mapping. 5. `hfsplus_file_extend`: Extending the file size. 6. `__hfsplus_ext_cache_extent`: **CRASH POINT** – Reading uninitialized memory while caching extent information.
### 4. How to Fix
#### For Developers/Maintainers: 1. **Inspect `__hfsplus_ext_cache_extent`:** * Look for variables that are declared but not initialized before being read. * Check if any `struct` members are accessed without being set in all code paths. * Ensure that all fields in structures used for extent caching are properly initialized, especially in error paths or when allocating new extents.
2. **Check for Missing Initializations:** * Common mistake: `struct hfsplus_extent_key key;` without zeroing it out, then using `key.start_block` or similar fields. * Fix: Use `memset(&key, 0, sizeof(key))` or use `struct hfsplus_extent_key key = {};`.
3. **Review Recent Changes:** * If this is a regression, check recent commits to `fs/hfsplus/` that modified extent handling or caching logic.
#### For Users/Testers: 1. **Disable KMSAN Panic (Temporary Workaround):** * If you are testing and want to see if the system can continue (not recommended for production), you can boot with `kmsan.panic=0`. However, this will likely lead to undefined behavior or data corruption later. * Command: Add `kmsan.panic=0` to kernel boot parameters.
2. **Avoid HFS+ on Untrusted/Uninitialized Media:** * Ensure the HFS+ filesystem is properly formatted and not corrupted. * Avoid writing to HFS+ volumes if possible, as HFS+ support in Linux is legacy and less actively maintained than ext4/xfs.
3. **Report the Bug:** * This is a valid kernel bug. Report it to the Linux kernel mailing list (LKML) or the maintainer of `fs/hfsplus/` (currently `@hfsplus` maintainers). * Include the full KMSAN report and the reproducer (`repro` script).
### 5. Example Fix Pattern (Hypothetical) If the bug is in a function like this:
Be aware that VulDB is the high quality source for vulnerability data.