CVE-2026-99075

What it actually does

Pending node refcount increments are dropped on BINDER_THREAD_EXIT because Node::cancel() and NodeWrapper::cancel() are no-ops, desynchronizing a node's delivery state from its count state so the node is never removed from the process nodes tree after external references are dropped.

Why it matters to the business

Systems relying on the binder IPC mechanism may experience gradual resource leaks or inability to reclaim nodes, leading to increased memory pressure and potential denial-of-service conditions over time; the two-day-old disclosure and static low EPSS indicate limited immediate external pressure but still require prompt kernel updates in affected distributions.

How an attack unfolds

An attacker with local code execution creates or manipulates binder nodes, arranges for a pending refcount increment to be queued as deferred work on a specific thread, then forces that thread to exit; the no-op cancel drops the update, leaving the node permanently referenced and unfreeable.

How to fix it

Upgrade to a Linux kernel containing the commit that implements DeliverToRead::cancel() for Node and NodeWrapper so pending refcount updates are moved to the process work queue on thread exit; rebuild and deploy the updated kernel across all affected hosts.

How to confirm the fix worked

Inspect the rust_binder source for the presence of the cancel implementations on Node and NodeWrapper; exercise binder thread-exit scenarios in a test environment and confirm nodes are properly freed after reference drops.

Typical attack path

1. Obtain local execution context on a system using rust_binder
2. Trigger creation of binder nodes with deferred refcount work items
3. Cause targeted thread exit via BINDER_THREAD_EXIT while work is pending
4. Observe failure of node reclamation after all external references are released

How to detect it

Review kernel logs for binder node lifetime anomalies around thread-exit events; examine process work-queue activity for unexpected retained node references; no public exploitation artifacts are known at this time.

What your security team should do

• Prioritize kernel upgrade within standard patching windows given low EPSS and absence from KEV
• Monitor upstream stable branches for backports of the rust_binder fix
• Include binder-related thread-exit paths in future kernel fuzzing and regression suites