CVE-2024-56555

What it actually does

Race condition in binder_add_freeze_work() allows concurrent binder_deferred_release() to move binder_node entries from proc->nodes rbtree into binder_dead_nodes list while iteration holds only inner_lock, causing rb_next() to dereference freed or unrelated memory and trigger global OOB read.

Why it matters to the business

Kernel panic or memory corruption on Android and embedded Linux devices using the binder IPC subsystem can lead to device reboots, denial of service, or potential privilege escalation requiring urgent kernel patching across fleets.

How an attack unfolds

An attacker with local access invokes the BINDER_FREEZE ioctl on a binder process while a concurrent binder_deferred_release() path is active; the temporary lock drop permits the node to be relocated, so subsequent rb_next() walks into the binder_dead_nodes global and reads out-of-bounds data.

How to fix it

Upgrade the Linux kernel to a version containing commit 6b1be1da1f8279cf091266e71b5153c5b02aaff6 or later; rebuild and deploy the fixed kernel image, then reboot affected systems. Where live patching is available apply the vendor Kpatch or Ksplice update.

How to confirm the fix worked

Confirm the running kernel contains commit 6b1be1da1f8279cf091266e71b5153c5b02aaff6 via 'uname -a' or /proc/version; attempt to reproduce the race with a binder freeze test binary and verify absence of KASAN reports; scan for the fixed binder.c source containing the 'proc is still alive' check before the rb_next loop.

Typical attack path

1. Obtain local code execution on a device using binder IPC
2. Open a binder device and create a process with nodes in proc->nodes
3. Trigger concurrent binder_deferred_release() via process exit or unmap
4. Call BINDER_FREEZE ioctl to enter binder_add_freeze_work() iteration
5. Trigger rb_next() on a node that has been moved to binder_dead_nodes
6. Cause KASAN-detected OOB read or kernel crash

How to detect it

Inspect kernel logs for KASAN reports mentioning rb_next and binder_add_freeze_work; correlate with audit logs showing rapid binder ioctl calls followed by process termination; look for crashes in the freeze task or binder_ioctl path around the published date.

What your security team should do

• Prioritize kernel updates on all Android and Linux devices exposing binder to untrusted processes
• Enable kernel hardening features such as KASAN in test environments to detect similar races
• Monitor vendor advisories for backported fixes in LTS kernels
• Restrict unprivileged access to binder devices via SELinux or seccomp where feasible