An experimental prerelease of GrapheneOS for the Pixel 8a is now available via https://staging.grapheneos.org/ including web installer support. It will be made available via https://grapheneos.org/ after we've done basic testing including testing the upgrade path to a future release.
Pixel 8a currently uses Android 14 QPR1 instead of Android 14 QPR2, meaning it's missing many improvements from the 2nd quarterly release including important privacy and security enhancements. It's likely Android 14 QPR3 will be released in June which should resolve this problem.
Android 14 QPR2 is the largest ever quarterly release of Android, because it's the first trunk-based development release. It brought a lot of what Android 15 is going to ship, largely under the hood with new user-facing features largely disabled but present in the code.
Android 14 QPR2 was released on March 4th but had a delay in publishing to AOSP due to issues with pushing the code which was finished by March 5th. GrapheneOS had a release based on it within a day of that, but it took a couple days to reach staging due to regressions we found.
Since the Pixel 8a is still using Android 14 QPR1, our initial release is based on porting our changes from our 2024030300 release which was the last one based on QPR1 (https://grapheneos.org/releases#2024030300). It has a current May security patch level, but this doesn't meet our usual standards.
It's missing improvements to GrapheneOS from March, April and May in addition to Android 14 QPR2 changes. We backported our change enabling PAC/BTI for userspace and are using a current GrapheneOS 5.15 LTS common kernel source tree. SHOULD be fixed with June update, QPR3 or not.
@ekuber The Bluetooth stack is currently a mix of C++ and Rust. Rust isn't used for everything yet. It has a lot more functionality in Rust than is currently being used. They switched to scanning via the Rust implementation in Android 13 and are gradually moving over for the rest but it's not finished at all. This vulnerability was in C++. As far as we know, Android has still never had a memory corruption bug discovered in Rust code.
@ekuber Rust libraries tend to get a CVE assigned based on the worst case scenario. In most cases, it's likely no one is actually using it in a way that would be vulnerable but rather it's simply a soundness issue creating unsafety via a safe API if it's used a certain way. Android wouldn't consider that to be a vulnerability if they could clearly see that nothing was using it that way. The Bluetooth bug we reported is considered High severity because it's a remotely exposed UAF bug.
@ekuber In our report, we said that it didn't seem to be a particularly bad use-after-free vulnerability and we weren't sure how to exploit it beyond DoS, but they still assigned High severity since it's a remotely exposed UAF. Could be Critical if there was a PoC doing more than crashing.
High/Critical get backported to older releases, currently 12, 13 and 14. Moderate/Low mostly don't get backports, only shipped in latest monthly/quarterly/yearly release, currently 14 QPR2 May release.
Add comment