Pixel 9: 0-click exploit chain reported by Project Zero

skim

I didn't see the CVEs listed in any of the releases.

https://projectzero.google/2026/01/pixel-0-click-part-1.html

GrapheneOS

skim We've never listed out the CVEs addressed by Android Security Bulletins or Pixel Update Bulletins but rather document those updates in the release notes. CVE-2025-54957 was fixed in the 2025-12-05 Pixel security patch level which was shipped when we moved to the December 2025 driver/HAL/firmware code in December 2025. If you want to know when the others were fixed, please search for them.

The security preview releases are only for Android Open Source Project patches being shipped early and only document the CVEs fixed early in the security preview releases, not the regular releases. There are similarly no CVEs listed for Linux kernel updates, SQLite updates, etc. but rather the update is listed. Android issues we fix ourselves don't have a CVE in the release notes either. You seem to be under the wrong impression that it's the norm for a CVE to be listed in the release notes due to that being how the set of security preview patches is applicable to GrapheneOS are listed in the security preview release notes. Security preview releases notes are a special thing and are not applicable to regular releases.

horde

GrapheneOS in https://projectzero.google/2026/01/pixel-0-click-part-3.html they said the following:

It is also notable that we have not been able to successfully exploit the Dolby UDC vulnerability on Mac or iPhone so far, as it was compiled with the -fbounds-safety compiler flag, which added a memory bounds check that prevents the bug from writing out of bounds. Dolby should consider providing such compiler based protections across all platforms. Apple also recently implemented MIE, a hardware-based memory-protection technology similar to Memory Tagging (MTE), on new devices. While MIE would not prevent the Dolby UDC vulnerability from being exploited in the absence of -fbounds-safety due to UDC using a custom allocator, it would probabilistically hinder an iOS kernel vulnerability similar to the BigWave driver bug from being exploitable.

Pixel 8 onwards shipped with MTE, but unfortunately, the feature has not been enabled except for users who opt into Advanced Protection mode, to the detriment of Pixel’s other users. Apple’s inclusion of memory protection features, despite their financial and performance cost, clearly paid off with regards to protecting its users from the UDC exploit as well as possible kernel privilege escalation. There is the potential to protect Android users similarly.

Does that mean that on GrapheneOS with MTE enabled it would have prevented this attack completely or partially?

de0u

horde Does that mean that on GrapheneOS with MTE enabled it would have prevented this attack completely or partially?

That is essentially two questions. This is not an expert opinion, but the blog post mentioned specific issues in the standard Android storage allocator, which I believe GrapheneOS does not use. And it is possible that Google Messages runs with MTE on GrapheneOS but not on Google's stock OS (I don't have a device with MTE, so I can't easily check). Finally, basically 100% of users of Google's stock OS have Google Messages installed; some fair fraction of GrapheneOS users don't, so those of us without Google Messages don't have the code path involving the Dolby codec that was the first step in the chain. Less code means less attack surface, in general.

But the other question is whether an attacker with this exploit would have been able to adapt it successfully against GrapheneOS. Developing the attack took a fair amount of work, and trying to retarget it would as well. Perhaps right now somebody is trying!

pi0

It would be interesting to know from a security perspective if GrapheneOS (pre-security patch) did effectively stop this attack. This can be tested because the proof-of-concept exploit was made public here with instructions: https://project-zero.issues.chromium.org/issues/428075495#attachment67118327

Here are the highlights of the Project Zero report from Natalie Silvanovich (the reporter) on her own Mastodon:

https://infosec.exchange/@natashenka/115901124481157929

Remarkably, iOS also integrates the UDC in a 1-click context, but this bug is not exploitable, because the codec is compiled with -fbounds-safety, which inserted bounds checking instructions, making the bug unreachable.

IMO, the biggest takeaway from this research is the huge promise shown by memory mitigations, both hardware and software, in protecting users against 0-days.