CVE-2025-22036 in Linux
Summary
by MITRE • 04/16/2025
In the Linux kernel, the following vulnerability has been resolved:
exfat: fix random stack corruption after get_block
When get_block is called with a buffer_head allocated on the stack, such as do_mpage_readpage, stack corruption due to buffer_head UAF may occur in the following race condition situation.
mpage_read_folio > do_mpage_readpage exfat_get_block bh_read __bh_read get_bh(bh) submit_bh wait_on_buffer ... end_buffer_read_sync __end_buffer_read_notouch unlock_buffer > ... ... ... ... > . . another_function > put_bh(bh) atomic_dec(bh->b_count) * stack corruption here *
This patch returns -EAGAIN if a folio does not have buffers when bh_read needs to be called. By doing this, the caller can fallback to functions like block_read_full_folio(), create a buffer_head in the folio, and then call get_block again.
Let's do not call bh_read() with on-stack buffer_head.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 02/15/2026
The vulnerability CVE-2025-22036 represents a critical stack corruption issue within the Linux kernel's exfat filesystem implementation that arises from improper handling of buffer_head structures during read operations. This flaw occurs specifically when the get_block function is invoked with a buffer_head allocated on the stack, creating conditions where use-after-free scenarios can lead to arbitrary stack corruption. The vulnerability manifests through a complex race condition involving multiple kernel subsystems including mpage_read_folio, do_mpage_readpage, and the exfat_get_block function, where the interaction between these components creates a window of opportunity for memory corruption attacks.
The technical root cause stems from the exfat filesystem driver's handling of buffer_head structures when processing read requests through the mpage subsystem. When do_mpage_readpage calls exfat_get_block, the function attempts to process buffer_head operations that involve stack-allocated structures. The race condition occurs during the buffer processing lifecycle where a buffer_head may be freed by put_bh() while still being referenced in the call stack, leading to stack corruption at the atomic_dec(bh->b_count) operation. This scenario directly maps to CWE-415: Double Free and CWE-416: Use After Free vulnerabilities, as the buffer_head structure is accessed after its memory has been released, creating potential for arbitrary code execution or system instability.
The operational impact of this vulnerability extends beyond simple system crashes, as it represents a potential pathway for privilege escalation and denial of service attacks. Attackers could potentially exploit this race condition to corrupt kernel memory structures, leading to system panics, data corruption, or in severe cases, arbitrary code execution with kernel privileges. The vulnerability affects systems running Linux kernels with exfat filesystem support, particularly those handling large volumes of read operations on exfat formatted storage devices. This flaw demonstrates the complexity of kernel memory management and highlights the critical importance of proper synchronization mechanisms when dealing with shared data structures in high-concurrency scenarios.
The patch implemented to address this vulnerability introduces a defensive mechanism that returns -EAGAIN when a folio lacks buffers during bh_read execution, forcing the caller to fall back to safer buffer creation routines such as block_read_full_folio(). This approach ensures that buffer_head structures are properly allocated within the folio context rather than on the stack, eliminating the race condition entirely. The solution aligns with ATT&CK technique T1068: Exploitation for Privilege Escalation by preventing the exploitation of memory corruption vulnerabilities through proper resource management. Additionally, this fix reinforces the principle of avoiding stack allocation for critical kernel data structures and demonstrates the importance of proper buffer lifecycle management in kernel space operations. The mitigation strategy effectively prevents the problematic code path while maintaining backward compatibility and system functionality, though it may introduce slight performance overhead due to the additional fallback mechanisms required for buffer creation.