CVE-2025-22036: exfat: fix random stack corruption after get_block
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.
<CPU 0> <CPU 1>
mpage_read_folio
<<bh on stack>>
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
<<keep going>>
...
...
...
...
<<bh is not valid out of mpage_read_folio>>
.
.
another_function
<<variable A on stack>>
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.
Security readout for executives and security teams
Plain-English summary
A race in the Linux exFAT filesystem can access a temporary object after its stack lifetime ends, corrupting kernel memory. A successful local attack could compromise confidentiality, integrity, and availability. Systems that do not process exFAT filesystems are less likely to reach the vulnerable path.
Executive priority
Prioritize affected systems that actively process exFAT, especially shared or sensitive hosts. Treat this as a high-priority kernel update, but current sources do not justify an internet-wide emergency response because exploitation is local and active exploitation is unconfirmed.
Technical view
CVE-2025-22036 is a CWE-416 use-after-free involving an on-stack buffer_head during exFAT get_block reads. A competing completion path may decrement the object after its caller has returned, corrupting reused stack memory. The kernel fix returns -EAGAIN so the caller falls back to a path using a folio-backed buffer_head.
Likely exposure
Exposure requires an affected Linux kernel and activity reaching the exFAT read path. The supplied record identifies affected releases beginning with 6.8 and lists later release boundaries, but its flattened version data is ambiguous. Confirm status through distribution backport information and inclusion of the cited commits.
Exploitation context
The CVSS 3.1 score is 7.8: local access, low complexity, low privileges, and no user interaction, with potentially high impact. The source bundle marks KEV false and provides no evidence of active exploitation or a public weaponized exploit.
Researcher notes
The vulnerable sequence crosses mpage_read_folio, do_mpage_readpage, exfat_get_block, bh_read, and asynchronous completion. Validation should focus on fix ancestry or vendor backport evidence rather than version-string comparison alone. The supplied affected-version representation is insufficient to state exact vulnerable ranges confidently.
Mitigation direction
Install a vendor-supported kernel containing the cited exFAT fix or an equivalent backport.
Confirm remediation against distribution advisories; package version numbers may not match upstream kernel versions.
Until patched, reduce exFAT filesystem use on affected systems where operationally feasible.
Follow vendor guidance for any additional mitigations or required reboots.
Validation and detection
Record the running kernel and distribution package versions on systems using exFAT.
Determine whether exFAT filesystems are mounted or processed on each candidate system.
Verify the installed kernel contains one of the cited fixes or an equivalent vendor backport.
After updating, reboot if required and confirm the remediated kernel is running.
Review kernel logs for exFAT or buffer_head faults; their absence does not prove remediation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-416: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
3Timeline events
1ADP providers
5Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-416 · source CWE mapping
Use After Free
Use After Free represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.