Any Android App Can Shut Down the Phone - We Found It in Three Hours Without Source Code

Any Android app on a Pixel can turn the phone off.

Not an app with root. Not an app that conned you through a permission prompt. A regular app, doing regular app things, hitting a use-after-free in the PowerVR GPU kernel driver. Phone goes down. As often as the attacker feels like it. We reported it to Google this morning.

It took three hours to find. We never saw the source code.

I want to be precise about that, because "AI found a kernel bug" is the kind of claim that earns an eye-roll, and mostly deserves one. There was no repo. No symbols. Nobody from the vendor on a call walking us through the driver. Xint Code chewed on a binary pulled off a shipped phone and came back before lunch was over.

A phone somebody can switch off whenever they feel like it is a phone that's off when you need it. That’s worth a patch on its own.

But the reboot is the floor. Tim Becker, who runs our engine team and has spent his career writing exploits against this exact class of bug, thinks the ceiling is considerably higher. His read is that privilege escalation and kernel memory disclosure are both realistically in play here.

So let me be boring for a second. We haven't built that exploit. We're not describing the mechanism while the fix is outstanding, and I'm not going to tell you we've got root on a Pixel, because we don't. 

What I will tell you is that a use-after-free in kernel driver code reachable from any app is exactly the shape both of those outcomes take. Tim's assessment is an assessment. The crash is a fact. Those two things get blended together constantly in security marketing, which is a large part of why nobody believes security marketing.

The reboot is annoying. An app with zero permissions reading kernel memory is a different animal, because it breaks the sandbox in the direction nobody watches. Not "the app took over your phone." More like "the app read things it had no business seeing, and your phone kept working perfectly."

Where the bug lives is its own story. Google moved Pixel graphics off Arm Mali onto Imagination's PowerVR with Tensor G5. PowerVR isn't unexplored ground; Imagination runs a public advisory page for GPU driver vulnerabilities, and that family has a documented run of kernel use-after-frees. The pattern was on the record. It shipped in the kernel of a flagship phone anyway.

Meanwhile a decade of researcher attention on Android GPU kernels points at Mali and Adreno, because that's where the phones were. Attention hasn't kept up with the silicon.

And GPU drivers aren't a backwater. They're one of the best-documented roads to root on Android, they keep turning up in commercial spyware chains, and they're a standing favorite for climbing out of the Chrome renderer sandbox. Attackers have been living in this neighborhood for years.

Which brings me to the thing I actually want to talk about. If it took three hours, why hadn’t anyone looked here before?

Here's how I've started thinking about it. A container ship pulls into port with forty thousand tons of sealed steel boxes, and every box arrives with a packing list. The packing list is authoritative in the sense that somebody signed it. It's also paper. Customs doesn't handle that by reading the paperwork more carefully. Customs x-rays the box.

Source code is the packing list. The binary is the cargo.

We've spent twenty years getting extremely good at reading paperwork. Repo scanning, dependency graphs, PR gates, all of it real work that catches real problems, and all of it pointed at the code you wrote. The code you wrote is a shrinking slice of what you ship. Your phone runs a kernel you didn't write, drivers licensed from a company you've never spoken to, firmware from a vendor three tiers down a supply chain nobody has mapped, and a rising share of code that nobody typed at all.

So this bug wasn't missed. It was invisible. It's not in anyone's repo. SAST has nothing to look at. SCA sees a vendor name and stops. Your pentest is scoped to your applications, because that's what pentests are scoped to, and because reverse engineering a GPU driver is a research project with a research budget attached.

That was a defensible place to land, for a long time, because opening one box took a specialist and six weeks. Six weeks of a senior researcher has to be justified to somebody, ranked against everything else that person could be doing, and it loses that argument most of the time.

Three hours doesn't have to be justified to anybody.

That's the whole shift. Nobody looked because looking was expensive. Looking isn't expensive anymore.

Others in our research team have been running source-versus-binary tests against our own targets and it keeps coming out the same way: the binary side finds high-severity bugs the source side never sees, because they sit in the part of the system source analysis can't reach. Same engine, different input, different bugs.

Other industries got here first, by the way. Customs x-rays containers instead of auditing exporters' notes. The FDA doesn't clear a device because the manufacturer says it reviewed its own design history (mostly). Both regimes showed up because failure got expensive enough that trusting paper stopped being an option. Software is on that road now. The Cyber Resilience Act is the first real milepost, and SBOM mandates are the polite opening move. An SBOM, note, is a packing list.

Technical details when Google ships the fix.

Until then the question isn't what this one bug does. It's how many sealed boxes are in your product, and when anybody last opened one. The first one takes three hours.