Exploiting LazyValue: How Use‑After‑Recycled Bugs Leak Android Parcel Data

Statement

1. This article shares research on a class of historical vulnerabilities; all reported bugs have been disclosed to vendors and fixed in the latest versions. 2. The technical research should only be performed within authorized scopes and must comply with relevant laws and regulations.

Background

The previous article ( Parcelable and Bundle: Love‑Hate Relationship (Part 1) – Read/Write Mismatch ) introduced two types of read/write mismatches that could cause validation failures. This article introduces a third issue.

Length‑Field Fix

Google added a length field before variable‑length types to ensure subsequent values start at the correct offset, preventing corruption of other data.

Regardless of errors while handling the value, the following value always reads/writes from the correct position.

LazyValue

LazyValue defers deserialization of a Bundle entry until it is accessed via Bundle.get*(). If the entry is never accessed, it remains untouched, avoiding the earlier read/write mismatch.

When reading, LazyValue jumps to the stored position and uses Parcel.readValue(), then clears the reference to the original Parcel. When writing, it copies the appropriate length of data to the target position.

Use‑After‑Recycled

Parcels can be recycled via Parcel.recycle() and later obtained with Parcel.obtain(), reducing allocations and GC pressure.

The caller of transact(...) typically uses Parcel.obtain() (sOwnedPool), while the callee receives a Parcel from sHolderPool.

If LazyValue is not parsed but the Parcel is recycled and later reused for another IPC, subsequent parsing of LazyValue may read data from the other IPC, leading to a use‑after‑recycled condition.

Returning to Previous Position

RemoteViews (a Parcelable with ReadWriteHelper) can be sent to SystemServer and later returned. Because of the helper, the Parcel may be recycled while LazyValue still points to it. When the LazyValue is later read, it can copy data from a different IPC.

Mid‑section

When a ReadWriteHelper is present, a parsing error can cause the Parcel to be recycled while LazyValue still references it, resulting in a use‑after‑recycled exploit.

If LazyValue’s length is negative, the read pointer can be moved backward, allowing access to earlier data.

These two points are the core of the patch.

Detail Issues

To exploit the vulnerability, one must find a trigger (e.g., an Account service) and craft a RemoteViews Bundle that contains a LazyValue pointing to a recycled Parcel.

Exploitation Points

The attacker can use MediaSession.setQueue(List<MediaSession.QueueItem>) to pass a RemoteViews‑derived Parcelable, then retrieve it via MediaSession.getController().getQueue(). The QueueItem type is erased at runtime, allowing the RemoteViews to be used.

Suspending attachApplication

The attachApplicationLocked(...) method runs quickly, so the attacker needs to pause it. By leveraging ParceledListSlice in ActivityTaskManagerService.moveTaskToFront(...), the attacker can block mGlobalLock and force the system to process the crafted Bundle, causing the LazyValue to be read and the exploit to trigger.

References

https://github.com/michalbednarski/LeakValue