CVE-2024-26606

What it actually does

The binder driver fails to issue a wakeup to epoll threads that have queued their own work via BINDER_WRITE_READ without a read buffer, allowing those threads to block indefinitely in epoll_wait even though pending work exists.

Why it matters to the business

Systems relying on binder IPC (primarily Android) may experience hung threads and stalled inter-process communication, leading to application or system-level denial of service.

How an attack unfolds

A local attacker opens the binder device, issues a BINDER_WRITE_READ command without supplying a read buffer, then enters epoll_wait; because the thread is not signaled for its own queued work, it remains blocked and subsequent commands also fail to wake it.

How to fix it

Upgrade the Linux kernel to commit dd64bb8329ce0ea27bc557e4160c2688835402ac or later; apply the stable backports that contain the same fix.

How to confirm the fix worked

Confirm the running kernel contains commit dd64bb8329ce0ea27bc557e4160c2688835402ac; verify the patch is present in the binder.c source and that epoll threads are now correctly woken on self-work.

Typical attack path

1. Open /dev/binder and initialize an epoll instance
2. Submit a BINDER_WRITE_READ ioctl without a read buffer
3. Enter epoll_wait (or equivalent) on the binder fd
4. Observe the thread remains blocked despite queued work

How to detect it

Review kernel logs and audit trails for repeated binder ioctl sequences followed by prolonged epoll_wait stalls; correlate with process state showing uninterruptible sleep on binder fds.

What your security team should do

• Prioritize kernel updates on all Android and Linux devices using binder
• Monitor vendor security bulletins for the backported fix in supported distributions
• Test epoll-based binder workloads after patching to confirm threads no longer hang