Driving Forward in Android Drivers

Seth Jenkins, a Google Project Zero researcher, argues that GPU drivers have drawn most Android kernel research, so attackers will likely look next at the other chipset drivers. Those drivers sit in the kernel and are reachable from apps through device files. He describes three ways to map this attack surface: walking the filesystem and testing access, reading kernel source for device creation calls, and checking SELinux policy for files untrusted apps may touch.

Applying these methods to three phones, he found few reachable drivers on a Pixel, with an edge TPU driver gated by an allow list. The MediaTek JPEG decoder driver was more exposed. Its locking had a flaw: a core check happened outside the mutex, so two threads could race and free the same file object twice. He explains how the resulting use-after-free could be shaped into an arbitrary read and write by reclaiming freed memory with a general-purpose kernel object, then used to free and reclaim a kernel array and disable SELinux enforcement.

The main takeaway is that Android vendor kernel code remains weakly reviewed, and that a freed object can still be useful without reclaiming it with a matching type. A live demo on stage crashed the phone on the first attempt and then reached root on the next run.