CVE-2023-52609

What it actually does

Race condition between mmput() and do_exit() in binder_update_page_range() allows a pinned remote mm to trigger exit_mmap() and fput() from the wrong task context, queuing ____fput() work as TWA_RESUME on a task that then sleeps indefinitely waiting for a reply from the now-dead peer, blocking binder_deferred_release() and all associated death notifications.

Why it matters to the business

Systems relying on binder IPC experience prolonged delays in process death notification delivery and resource cleanup, which can stall dependent services, increase memory pressure, and complicate container or VM orchestration on affected Linux and Android kernels.

How an attack unfolds

An attacker arranges two binder-connected tasks so that one performs mmget_not_zero() on the other's address space while the target task simultaneously exits; the resulting cross-task fput() work is deferred on a thread that blocks in binder, postponing all death notifications until an unrelated binder transaction wakes it.

How to fix it

Upgrade the Linux kernel to commit 95b1d336b0642198b56836b89908d07b9a0c9608 or later. For AlmaLinux 8 deployments, update the listed packages to the exact fixed module versions: fuse-overlayfs-1.4.0-2.module_el8.6.0+2876+9ed4eae2, criu-3.15-1.module_el8.6.0+2876+9ed4eae2, slirp4netns-1.1.8-1.module_el8.6.0+2876+9ed4eae2, conmon-2:2.0.26-1.module_el8.6.0+2876+9ed4eae2 and equivalent updates for the remaining affected container packages.

How to confirm the fix worked

Confirm the running kernel contains commit 95b1d336b0642198b56836b89908d07b9a0c9608, verify package versions match the fixed module strings above, and exercise binder death-notification paths under concurrent exit to ensure release work completes promptly.

Typical attack path

1. Establish binder connection between attacker-controlled task A and target task B
2. Trigger concurrent mmget_not_zero() in A and do_exit()/exit_mm()/mmput() in B
3. Force Task A to sleep inside binder waiting for a reply from the now-dead B
4. Observe delayed execution of binder_deferred_release() and death notifications

How to detect it

Search kernel logs and binder debugfs for prolonged stalls between process exit and delivery of death notifications; correlate with tasks blocked inside binder_deferred_release() or waiting on TWA_RESUME work.

What your security team should do

• Prioritize kernel and container runtime updates on all systems exposing binder or using the listed AlmaLinux 8 modules
• Monitor upstream stable trees for additional backports of the mmput_async() fix
• Review container orchestration workloads for heavy binder usage and schedule maintenance windows before the next patch cycle