GrapheneOS

Android Security Bulletin for April 2025 has 2 more vulnerabilities marked as being exploited in the wild.

GrapheneOS fully prevented exploiting both vulnerabilities for locked devices, made both far harder to exploit while unlocked and already had both patched for a while too.

CVE-2024-53150: heap overflow (read) in a Linux kernel USB sound card driverCVE-2024-53197: heap overflow (write) in a Linux kernel USB sound card driver

These vulnerabilities were being exploited by Cellebrite for data extraction from locked Android devices without GrapheneOS.

We have a post from late February about CVE-2024-53197 and 2 other bugs exploited by Cellebrite which they were blocked from exploiting by GrapheneOS:

https://discuss.grapheneos.org/d/20402-cellebrite-exploits-used-to-target-serbian-student-activist

CVE-2024-53150 is almost certainly part of the same batch of vulnerabilities they’ve been exploiting.

https://discuss.grapheneos.org/d/20401-grapheneos-improvements-to-protection-against-data-extraction-since-2024%C2%A0covers how we’ve greatly improved the GrapheneOS defenses against these attacks since early 2024. We’re continuing to work on improving it.

We helped get firmware security improvements to Pixels and are advocating for further hardware/firmware changes.

This is an early April security update release based on the April 2025 security patch backports since the monthly Android Open Source Project and stock Pixel OS release scheduled for this month hasn’t been published yet.

Tags:

2025040700 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets) Changes since the 2025040400 release:

full 2025-04-01 security patch level

New 25Gbps sponsored server from Macarne is now handling all of our OS/package update traffic for Europe, Africa, Middle East, Central Asia and South Asia:

https://grapheneos.social/@GrapheneOS/114264453740567840

We're looking into the several offers we received for new servers in East and West North America.

Rolling out our recent relatively small OS update with an 70M delta to Stable for all devices uses ~2Gbps for ~6 hours in Europe after a short 3Gbps spike. It then gradually drops. Europe handles ~40% more than North America. Quarterly/yearly updates tend to be 400MB to 800MB.

We also need to figure out the separate issue of needing more VPS instances broadly distributed around the world for our network services like network time. We aren't yet sure how large our own Wi-Fi AP database for network location is going to be so we aren't sure on specs yet.

Tags:

• 2025040400 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025032500 release:

• Sandboxed Google Play compatibility layer: remove StatsManager from hidden services and replace that approach with stubbing out all of the methods since Play services recently introduced new code using it that's missing a null check and triggers a null pointer exception which has blocked us from pushing out the newer versions of Play services beyond our App Store's Alpha channel
• Network Location: switch to making at most a single request to the service per position estimation by requesting up to 40 Wi-Fi APs at once
• Network Location: optimize making requests to the service for Wi-Fi AP data
• Network Location: optimize Rust JNI bindings to the point that it no longer causes a noticeable overhead without introducing unsafe code (it could be optimized further with unsafe code to cache more JNI binding work but the difference is insignificant so we don't plan to do it)
• Network Location: use correct Accept header value to more closely match macOS to avoid future compatibility issues
• fix upstream system_server crash from null pointer exception in F2fsUtils
• add infrastructure for more restricted access to global and per-user settings instead of allowing all system apps to read them and all privileged systems apps with the WRITE_SECURE_SETTINGS privileged permission to write them
• further restrict access to all global and per-user settings added by GrapheneOS with our new infrastructure
• replace disabling the unused ADD_USERS_WHEN_LOCKED and ENABLE_EPHEMERAL_FEATURE settings at boot with a new approach of making settings immutable in the code, which we can expand in the future to other problematic settings not used by GrapheneOS
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.131
• kernel (6.1): drop revert for upstream USB fix causing DisplayPort alternate mode regression due to another upstream patch successfully fixing it
• kernel (6.6): update to latest GKI LTS branch revision
• Vanadium: update to version 135.0.7049.38.0
• GmsCompatConfig: update to version 155
• GmsCompatConfig: update to version 156

Macarne has provided a sponsored server to replace our current EU update servers so we can handle current traffic and near future growth. Ryzen 9950X, 128GB RAM, 2x 2TB NVMe and most importantly 25Gbps bandwidth. It’s greatly appreciated!

https://macarne.com/

We use GeoDNS and round-robin DNS to distribute load across our servers with automatic failover. Ideally, we can find a good 2nd provider willing to provide sponsored/discounted 2x 10Gbps servers to cover each coast of North America. 2x 25Gbps would be great but not needed yet.

Our existing setup was 8x 2Gbps OVH VPS instances with 4 in Quebec, 2 in France and 2 in Germany. This was getting increasingly overloaded for the 4 major releases per year, and the largest one (Android 16) is coming up soon. European bandwidth usage is also around 50-60% higher.

We currently have 16Gbps total bandwidth for our update servers and that's not nearly enough for major releases anymore. Rather than further scaling up our current 2Gbps unmetered VPS approach, we're currently looking into other options. OVH lacks cost effective 10Gbps servers.

We've made 2 attempts at talking to OVH about offering us something different than their publicly available products which hasn't gone anywhere. We likely need to move this part of our infrastructure to 1 or 2 other providers with unmetered 10Gbps dedicated servers like Tempest.

For an idea of what we're looking for, see the 10Gbps options at https://tempest.net/dedicated-servers with 64GB memory. They're also willing to give us a significant discount, which other major providers haven't offered. Tempest is currently IPv4-only though, which isn't ideal for our usage.

Yuh app from Swissquote temporarily disabled Play Integrity API enforcement due to complaints from GrapheneOS users and is reimplementing their security checks with support for GrapheneOS based on https://grapheneos.org/articles/attestation-compatibility-guide. We removed it from the list of apps banning GrapheneOS.

See https://github.com/PrivSec-dev/banking-apps-compat-report/issues/509#issuecomment-2753783269 for details. They responded on the issue.

This is one of several apps which has recently stopped banning GrapheneOS due to the guide we provide on using hardware-based attestation as an alternative or full replacement for the Play Integrity API.

Apps enforcing enforcing a Play Integrity API check have nothing to lose by permitting GrapheneOS too via hardware attestation. You'll get positive reviews from our rapidly growing userbase instead of negative. GrapheneOS is much more secure than anything Play Integrity permits.

Changes in version 156:

• add stub for MediaRouter2.getInstance() to avoid a silent crash

A full list of changes from the previous release (version 155) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims.

Android has always taken the approach of it being developed in private and then having the full sources and commit history published for each stable release. This approach used to be the norm for open source software many years ago, but now most projects do a lot of their development in the open.

Commit history being available also didn't used to be the norm many years ago but rather only tarballs for releases. It's very important for them to provide it and they're still going to be doing that.

Certain sub-projects were developed in the open as part of the public Android Open Source Project repositories in the main branch but the bulk of the work was done in private. They maintained both a public main branch and an internal development branch and had to merge back and forth between them.

Recently, Google announced they'll be shifting most of the small subset of the OS developed in the AOSP main branch to being developed internally instead. The full commit history will still be available when stable releases are published as it for the majority of AOSP developed that way already.

AOSP main was not where most of the OS was developed and would get most of those changes merged into it shortly after each stable release.

AOSP main also doesn't correspond to Developer Preview and Beta releases, which are separate branches and what we need for porting before a Stable release.

The small subset of the OS developed via AOSP main moving away from it won't have a major impact on GrapheneOS. It did not provide us with early access to the code we need for porting GrapheneOS to an upcoming release before the day it gets released. That already required having partner access.

Android is remaining open source and simply being slightly less open about the development of certain components. We won't be able to see the commits as they're made for that small subset of components anymore but rather need to wait until they publish the full commit history for stable releases.

In contrast with Android, Chromium is developed almost entirely in the open and we can port and test all of our changes to the upcoming releases before there's a Stable release. This is very helpful and makes maintenance much easier for us. Doing this for Android already required partner access.

We've already been in the process of figuring out how to get partner access in a way that will be reliable and long term. There was only one year where we had early access to a new major release. We haven't had it for several years and we still manage to get the yearly releases out in a couple days.

Changes in version 155:

• disable AnomalyConfigIntentOperation to avoid a null pointer exception from the StatsManager service not being accessible
• update Android Gradle plugin to 8.9.1
• update Gradle to 8.13

A full list of changes from the previous release (version 154) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims.

Changes in version 134.0.6998.135.0:

• update to Chromium 134.0.6998.135

A full list of changes from the previous release (version 134.0.6998.135.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

Tags:

• 2025032100 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025031400 release:

• Sandboxed Google Play compatibility layer: improve support for overriding Gservices flags to avoid situations where our overrides aren't used leading to compatibility issues (this should fix a recent Play services crash that's being reported)
• Sandboxed Google Play compatibility layer: improve support for overriding phenotype flags and fix flag overrides not being applied in some cases
• fix 2 upstream lockscreen layout bugs with split shade used on folding phones (for the inner screen) and tablets
• fix upstream lockscreen layout bug with placement of alarm and Do Not Disturb information
• fix upstream lockscreen layout bug hiding date text when media is playing
• enable support for the new desktop mode as an additional developer option toggle (Pixel Tablet already has this as the main toggle)
• Terminal (virtual machine management app): backport upstream improvements
• System Updater: raise download buffer size
• System Updater: delete update package immediately after completion
• System Updater: fall back to downloading and installing a full update if an incremental (delta) update fails initialization which occurs when a firmware or OS image has been corrupted (extremely rare edge case due to verified boot)
• System Updater: retry faster if installation fails
• System Updater: improve error checking to provide better error messages
• System Updater: close update package zip file earlier
• Network Location: require TLSv1.3 for GrapheneOS services instead of either TLSv1.2 or TLSv1.3
• kernel (6.6): update to latest GKI LTS branch revision
• Seedvault: update to 15-5.4 (will be replaced with a better backup implementation in the future)
• stop disabling inclusion of device diagnostics functionality now that it's available in the Android Open Source Project
• Vanadium: update to version 134.0.6998.108.0

Android 15 QPR2 introduced a bug where the Microphone indicator will sometimes remain active after Microphone usage ends. We've confirmed this issue is present in the stock Pixel OS for both Android 15 QPR2 and Android 16 Beta 3. We're working resolving the regression but haven't figured it out yet.

Here are several upstream issue reports:

https://issuetracker.google.com/issues/388151378 https://issuetracker.google.com/issues/392596949 https://issuetracker.google.com/issues/401832184

It does not mean that apps are actually continuing to use the Microphone. They introduced a bug where the OS can miss that it stopped.

I really like GrapheneOS but I hate pixel UI. I know you can use a launcher, but I would prefer something like color OS. Is there any timeline on when graphene might be ported to other devices?

Changes in version 134.0.6998.108.0:

• update to Chromium 134.0.6998.108
• add support for using passkeys without Play services via the Android 15 credential manager (not every passkey provider supports this)
• disable barcode and text detection features depending on Play services dynamite modules to avoid violating Dynamic Code Loading (DCL) via Storage restrictions especially since it can't be turned off for base OS apps by users

A full list of changes from the previous release (version 134.0.6998.95.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

Second donation to GrapheneOS by the Proton Foundation:

https://discuss.grapheneos.org/d/21033-second-donation-to-grapheneos-by-the-proton-foundation

Chromium team developed a new font rendering library (Skrifa) as part of their Fontations library written in Rust. Skrifa now provides memory safe rendering for all web fonts since Chromium 133 for Android, ChromeOS and other Linux distributions:

https://developer.chrome.com/blog/memory-safety-fonts

This is a post from 2022 about Android:

https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language.

Android has much more heavily adopted Rust since then. It’s nice to see Chromium starting.

Android is using Rust as the low-level language of choice for new low-level components outside of the Linux kernel and is working towards enabling using it for new drivers. They’re not mass porting code to it but rather it has largely replaced C++ for new components and rewrites.

Latest release of Vanadium has support for passkeys without Google Play services via the Android 15 credential manager:

https://grapheneos.social/@GrapheneOS/114186195115859187

Proton Pass and Bitwarden are examples of apps providing passkeys without Play services.

Tags:

• 2025031400 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025031300 release:

• Sandboxed Google Play compatibility layer: add back default values to the API definitions for our reimplementation of the Google Play location service since dropping them in the previous release (2025031300) broke compatibility with a subset of apps and prevented us moving it past our Alpha channel (all the improvements from the previous release are still present)
• adevtool: fix support for checking stock OS kernel revision

Since 6th/7th/8th generation Pixels have moved to the Linux 6.1 LTS branch with Android 15 QPR2 from 5.10 (6th/7th gen) and 5.15 (8th gen), we've closed issues filed about kernel crashes for those devices. Many kernel bugs will be gone and any remaining ones need updated reports.

GrapheneOS adds user-facing system crash reporting to make up for us not having automated crash reporting for privacy reasons. Any hardware lockup or hard reset is called a kernel crash, including holding power, so most aren't useful since they just show a hardware lockup/reset.

We report some forms of system crashes by default including memory corruption detected by hardware memory tagging in both the kernel and userspace. Full reporting can be enabled in Settings > Security & privacy > More security & privacy > Notify about system process crashes.

We don't have it fully enabled by default because we'd get a flood of reports about hardware lockups/resets while devices are asleep and not being used, etc. Rest are near entirely upstream bugs and we can't fix all of them. We focus on the ones detected by our security features.

Workaround for very rare fingerprint firmware glitch with Android 15 QPR2:

https://discuss.grapheneos.org/d/20636-workaround-for-very-rare-fingerprint-firmware-glitch-with-android-15-qpr2

This applies to the stock Pixel OS, GrapheneOS or another OS based on Android 15 QPR2 running on Pixel devices with the OS providing the latest firmware released this month.

This issue appears to be specific to the non-Pro Pixel 9. We have no reports of it happening on any other device models. We're continuing to look into it. Perhaps we can find a workaround for it before there's a patch for the stock OS / AOSP such as retrying connecting to it.

For our next release after 2025030800, we've added support for the Android 15 QPR2 Terminal for running other operating systems using hardware virtualization. It's currently only a terminal but Android is adding support for graphics and GPU acceleration for a future release.

Android has a greatly overhauled desktop mode on the way to replace the current primitive proof of concept in developer options. 6th gen Pixels added hardware-based virtualization support and 8th gen Pixels added USB-C DisplayPort alternate mode. It will all come together soon.

Overhauled desktop mode is already partially shipped as a disabled-by-default feature. Android enables some of it for the Pixel Tablet already but not Pixel phones. We plan to enable the same feature flags for phones too. Either way, it's an experimental developer option for now.

Beyond using a phone or tablet as a desktop by connecting a display, keyboard, mouse, etc. to the USB-C port, we want to eventually have support for GrapheneOS on laptops. There's currently no laptop close to meeting the hardware requirements we cover at https://grapheneos.org/faq#future-devices.

On Pixels, virtualization implemented based on pKVM (see https://source.android.com/docs/core/virtualization/security for how it's different from KVM) and CrosVM from extended with Android specific code. CrosVM is written in Rust so it fits in well with Android using Rust for new or rewritten low-level components.

This release adds support for the experimental virtual machine management app introduced in Android 15 QPR2. It currently only provides support for managing a single VM and interacting with it via a WebView-based terminal. Android is in the process of adding support for graphics and GPU acceleration for a future release. For now, it's only available in developer options due to being highly experimental. We don't recommend using developer options on a production device, but you can temporarily enable it to turn on this feature and turn them back off without it being disabled like most developer options. The data inside it should currently be treated as disposable rather than relying on it not losing it from a bug or a backwards incompatible update. We plan to support choosing other guest operating systems beyond the Debian-based image provided by Android along with taking far more advantage of the virtualization infrastructure.

Tags:

• 2025030900 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025030800 release:

• SystemUI: re-enable migrate_clocks_to_blueprint and communal_hub flags with workarounds for upstream issues when using standard AOSP UI components instead of Pixel OS components
• Android Debug Bridge: fix upstream crash caused by a race condition that sometimes unregistered a closed file descriptor from epoll
• Sandboxed Google Play compatibility layer: fix issue breaking RPC transactions which impacts the Terminal app
• Sandboxed Google Play compatibility layer: add implementation of isGoogleLocationAccuracyEnabled() to the location rerouting implementation always returning true to fix compatibility with apps checking for it
• Sandboxed Google Play compatibility layer: fix definition of IStatusCallback.onCompletion() to slightly improve performance
• allow Terminal app to use WebView JIT since it requires WebAssembly
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.80

Changes in version 134.0.6998.95.0:

• update to Chromium 134.0.6998.95

A full list of changes from the previous release (version 134.0.6998.39.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

Our 2025030900 release currently in the Beta channel is the first one with support for managing hardware-based virtual machines via the Terminal app in Android 15 QPR2. Since then, we've backported massive improvements to the feature for an upcoming new release, maybe even today.

Backports include terminal tabs, GUI support with opt-in GPU hardware acceleration (ANGLE-based VirGL until GPU virtualization support is available), speaker/microphone support and fixes for a bunch of bugs including overly aggressive timeouts. We're working on VPN compatibility.

At the moment, the Terminal app isn't compatible with having a VPN in the Owner user. It only works if VPN lockdown (leak blocking) is disabled and the VPN allows local traffic to pass through. It's also not clear how it SHOULD interact with a VPN since VPNs are profile-specific.

As a preview of what's going to be possible in the upcoming release of GrapheneOS, here's a screenshot from a Pixel Tablet running desktop Chrome in a virtual machine with basic GPU acceleration via ANGLE on the host. The infrastructure is a lot more robust than the Terminal app.

Our next release also enables running the Terminal app in secondary users. There's still the temporary limitation of only being able to use a single VM on the device at a time because the dedicated internal network interface it uses for the Terminal app isn't split up at all yet.

GUI VM support will have 2 main use cases:

1. Running a specific app or an entire profile via GrapheneOS virtual machines seamlessly integrated into the OS.
2. Running Windows or desktop Linux applications with desktop mode + USB-C DisplayPort alt mode on the Pixel 8 and later.

This virtual machine management app (Terminal) will be handling the 2nd case. It's essentially already available in a very primitive way. We expect this to become much more usable and robust entirely from the upstream Android work on the virtual machine and desktop mode features.