CVE-2025-22036: exfat: fix random stack corruption after get_block

Published Apr 16, 2025
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

exfat: fix random stack corruption after getblock

When getblock is called with a bufferhead allocated on the stack, such as dompagereadpage, stack corruption due to bufferhead UAF may occur in the following race condition situation.

<CPU 0> <CPU 1> mpagereadfolio <<bh on stack>> dompagereadpage exfatgetblock bhread bhread getbh(bh) submitbh waitonbuffer ... endbufferreadsync endbufferreadnotouch unlockbuffer <<keep going>> ... ... ... ... <<bh is not valid out of mpagereadfolio>> . . anotherfunction <<variable A on stack>> putbh(bh) atomicdec(bh->bcount) stack corruption here

This patch returns -EAGAIN if a folio does not have buffers when bhread needs to be called. By doing this, the caller can fallback to functions like blockreadfullfolio(), create a bufferhead in the folio, and then call getblock again.

Let's do not call bhread() with on-stack bufferhead.

Other sources

In the Linux kernel, the following vulnerability has been resolved:

exfat: fix random stack corruption after getblock

When getblock is called with a bufferhead allocated on the stack, such as dompagereadpage, stack corruption due to bufferhead UAF may occur in the following race condition situation.

<CPU 0> <CPU 1> mpagereadfolio <<bh on stack>> dompagereadpage exfatgetblock bhread bhread getbh(bh) submitbh waitonbuffer ... endbufferreadsync endbufferreadnotouch unlockbuffer <<keep going>> ... ... ... ... <<bh is not valid out of mpagereadfolio>> . . anotherfunction <<variable A on stack>> putbh(bh) atomicdec(bh->bcount) stack corruption here

This patch returns -EAGAIN if a folio does not have buffers when bhread needs to be called. By doing this, the caller can fallback to functions like blockreadfullfolio(), create a bufferhead in the folio, and then call getblock again.

Let's do not call bhread() with on-stack bufferhead.

NVD

Affected Software

4 affected components
Linux Linux kernel
Linux Linux kernel>=6.8<6.12.23
Linux Linux kernel>=6.13<6.13.11
Linux Linux kernel>=6.14<6.14.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Apply the described kernel fix for exfat: ensure get_block/bh_read do not operate on a buffer_head allocated on the stack. Instead, create a buffer_head in the folio (e.g., like block_read_full_folio()), then call mpage_read_folio, and use put_bh(bh) after submit_bh per the patch logic to avoid buffer_head UAF and stack corruption.

    Linux kernel (exfat) do not call bh_read() with an on-stack buffer_head = true

Event History

Apr 16, 2025
CVE Published
via MITRE·02:11 PM
Data Sourced
via MITRE·02:11 PM
DescriptionSeverity
Data Sourced
via Red Hat·03:03 PM
DescriptionSeverityAffected Software
Data Sourced
via NVD·03:15 PM
RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2025-22036?

CVE-2025-22036 has been classified as a high-severity vulnerability due to the potential for stack corruption and exploitation.

2

How do I fix CVE-2025-22036?

To mitigate CVE-2025-22036, it is recommended to update the Linux kernel to a version where the vulnerability has been patched.

3

Which versions of the Linux kernel are affected by CVE-2025-22036?

CVE-2025-22036 affects Linux kernel versions from 6.8 to 6.12.23, 6.13 to 6.13.11, and 6.14 to 6.14.2.

4

What impacts can result from CVE-2025-22036?

Exploitation of CVE-2025-22036 can lead to possible stack corruption, resulting in system instability or crashes.

5

Who should be concerned about CVE-2025-22036?

System administrators and users running affected versions of the Linux kernel should prioritize addressing CVE-2025-22036.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203