CVE-2025-22036

What it actually does

Use-after-free on a stack-allocated buffer_head in exfat_get_block during bh_read, allowing concurrent put_bh to corrupt stack memory after the original buffer_head goes out of scope.

Why it matters to the business

Systems running affected kernels with exFAT volumes may experience crashes, memory corruption, or local privilege escalation; widespread container tooling deployments increase exposure across many hosts.

How an attack unfolds

An attacker triggers a race during mpage_read_folio where one CPU holds a stack buffer_head while another performs end_buffer_read_sync and later put_bh, causing UAF write into stack variables of a subsequent function and enabling privilege escalation.

How to fix it

Upgrade the Linux kernel to commit 49b0a6ab8e528a0c1c50e37cef9b9c7c121365f2 or later; for Red Hat Enterprise Linux 9.2 systems also update podman packages to 2:4.4.1-21.el9_2 or newer.

How to confirm the fix worked

Verify the running kernel contains commit 49b0a6ab8e528a0c1c50e37cef9b9c7c121365f2; confirm podman packages report version 4.4.1-21.el9_2 or higher; test exFAT read workloads under concurrent I/O.

Typical attack path

1. Mount an exFAT filesystem and trigger do_mpage_readpage on a folio without pre-existing buffers.
2. Force concurrent bh_read and buffer completion paths across CPUs.
3. Reuse the freed stack slot with attacker-controlled data via put_bh.
4. Execute code or crash the kernel from the corrupted stack frame.

How to detect it

Search kernel logs for oops or stack traces mentioning exfat_get_block, bh_read, put_bh, or buffer_head UAF; inspect crash dumps for corrupted stack frames after exFAT I/O activity.

What your security team should do

• Apply kernel and podman updates within the next maintenance window.
• Restrict exFAT mounts to trusted media until patches are deployed.
• Monitor for kernel oops and stack trace patterns involving exfat_get_block and buffer_head.