CVE-2025-40295 in Linux
Sumário
de VulDB • 07/08/2026
Based on the kernel log snippet and the explanatory text provided, this is a **kernel bug report/patch description** regarding an integer overflow (left-shift underflow) in block layer code when `CONFIG_TRANSPARENT_HUGEPAGE` is enabled.
### Summary of the Issue
1. **Trigger Condition**: * The system has `CONFIG_TRANSPARENT_HUGEPAGE=y`. * This allows a maximum logical block size (`logical_block_size`) of **64 KiB** (2^16 bytes). * In `set_init_blocksize()`, the inode's `i_blkbits` is set to **13** (since 8 KiB = 2^13, which fits within limits for some paths, but note: the text says it sets it to 13, implying an 8KB block size was chosen or defaulted).
2. **The Bug**: * The crash occurs in a function that performs bit-shifting operations involving `i_blkbits`. * Specifically, there is likely code like: `(size >> i_blkbits)` or similar arithmetic where shifting by an incorrect value causes undefined behavior or wraps around due to integer underflow/overflow. * The RIP (`0x75054cba4a06`) points into a user-space library (likely glibc), but the crash happened in kernel space during a syscall, as indicated by `entry_SYSCALL_64_after_hwframe` and the stack trace showing kernel functions like `do_syscall_64`.
3. **Why File I/O Doesn’t Trigger It**: * For most filesystems (except XFS), `sb_set_blocksize()` caps `s_blocksize_bits` at `PAGE_SHIFT` (typically 12 for 4KB pages). * During inode allocation, `inode->i_blkbits` is set from `sb->s_blocksize_bits`. So it’s usually ≤ 12. * XFS has the `FS_LBS` flag and can handle larger block sizes, but its I/O paths bypass `submit_bh_wbc()`, so they don’t hit this specific vulnerable code path.
4. **The Fix (from [EB])**:
* Use `folio_pos()` to get the correct offset/position from a folio instead of relying on potentially incorrect bit-shifts based on `i_blkbits`. * Consolidate shifts by `i_blkbits` into fewer, safer operations.
### Likely Vulnerable Code Pattern
The bug likely exists in code that converts between byte offsets and block indices using:
```c // Example vulnerable pattern (hypothetical) sector_t sector = offset >> inode->i_blkbits; // If i_blkbits is wrong or large, this can misbehave ```
Or more specifically, when dealing with folios/buffers in the block layer where `i_blkbits` might not accurately reflect the actual page/folio size being used for I/O.
### Recommended Fix Approach (as suggested by [EB])
Instead of manually shifting based on `inode->i_blkbits`, use kernel helpers that understand folio/page sizes:
```c // Instead of: // unsigned long block = offset >> inode->i_blkbits;
// Use: unsigned long block = folio_pos(folio) >> PAGE_SHIFT; // Or similar, depending on context ```
Or ensure that any shift operation involving `i_blkbits` is validated or replaced with functions like `folio_size()` and proper alignment checks.
### Conclusion
This patch fixes a potential kernel panic/crash caused by incorrect bit-shifting arithmetic in the block layer when transparent huge pages are enabled, particularly affecting certain block device operations. The fix involves using safer folio-based APIs instead of raw shifts on `i_blkbits`.
If you want to get best quality of vulnerability data, you may have to visit VulDB.