GrapheneOS [Unofficial]

Changes in version 13:

• add support for ARM hardware memory tagging (MTE) which has been shipped in production on GrapheneOS for the past year (see the README section on memory tagging for details)
• Android: implement fatal_error() via async_safe_fatal() for improved logging
• Android: restore the default SIGABRT handler in fatal_error() before aborting to avoid deadlocks with crashlytics
• Android: remove redundant warning switches for Android
• fix -Wimplicit-function-declaration warning with GCC 14
• update libdivide to 5.1

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

See the README for this release for an overview of the project and many details about the design goals and implementation.

This is a standalone release for use outside of GrapheneOS. GrapheneOS ships these changes shortly after they're implemented as part of our OS releases rather than waiting for these releases.

These integer tags are the standalone releases, while date style tags such as 2024101200 and 2024101200-caimito are part of GrapheneOS releases and may contain GrapheneOS-specific changes such as workarounds for latent memory corruption bugs encountered in the wild while waiting for an upstream or downstream fix.

Pixel 4a (5G), Pixel 5 and Pixel 5a are end-of-life and shouldn't be used anymore due to lack of security patches for firmware and drivers. We provide extended support for harm reduction.

Tags:

• 2024101200-redfin (Pixel 4a (5G), Pixel 5)
• 2024101200 (Pixel 5a, 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, emulator, generic, other targets)
• 2024101200-caimito (Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold)

Changes since the 2024100800 release:

• hardened_malloc: preserve hardware memory tagging enforcement flag for slab mappings when releasing free slabs
• hardened_malloc: improve accuracy of probability hint for hardware memory tagging branches
• temporarily revert enforcing minimum 64kiB stack guard size for arm64 since Facebook recently included a buggy stack overflow check for the React Native Hermes runtime that's incompatible with larger gap sizes and beginning to be shipped by apps
• Log Viewer: add "bootloader unlocked" and "dev options enabled" flags to header
• Log Viewer: add "More info" button to native crash reports
• Log Viewer: include contents of App Not Responding (ANR) stack traces file in ANR error reports
• Log Viewer: omit processUptime header line when it's unknown
• Settings Intelligence (Settings search): fix upstream bug resulting in corruption of the query history database which leads to the search crashing
• Launcher: mark 2x2 workspace option as being for phones
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.54
• adevtool: update out-of-band carrier settings
• Vanadium: update to version 129.0.6668.100.0

We've improved the layout of the list of releases on our site and added the Alpha channel to the list. The overall changes should make it more useful and easier to understand:

https://grapheneos.org/releases#devices

Each official release of GrapheneOS goes through Alpha and Beta before Stable.

Facebook shipped buggy stack overflow detection in the Hermes JavaScript engine used by React Native:

https://github.com/facebook/hermes/issues/1535

It breaks when the default stack guard is 64k instead of 4k. The standard 64-bit ARM Linux ABI requires 64k. So far only 1 person noticed a broken app.

We're going to be temporarily reverting our change in today's release before Facebook's broken code reaches more apps. We tried lying to apps about the stack layout to hide this change but that breaks compatibility much more. We'll have to detect the Facebook library instead.

Not particularly important since we weren't planning on switching to standard 64k stack probes instead of 4k stack probes to avoid risk. However, it's nicer if it's larger to cover 3rd party code without stack probes. Very minor compared to other things blocked by app compat.

The main feature that's blocked due to third party app bugs is enabling hardware memory tagging by default for all user installed apps. That works fine but catches many memory corruption bugs. We might put the toggle into the setup wizard so that most users end up enabling it.

We want to disable the 32-bit ARM system call ABI in the kernel config on devices without 32-bit app support. Certain widespread anti-tampering frameworks use it even on devices like the Pixel 8 without CPU level support for 32-bit. We'll have to extend the seccomp filters.

Enabling ShadowCallStack for Vanadium worked well but caused issues with WebView-based apps, likely due to anti-tampering code. This would be nice even on the recent devices with PAC and MTE until we have stack allocation MTE enabled... which is blocked due to app bugs for now.

There's a highly inaccurate article about Pixels from Cybernews making the rounds everywhere in privacy communities. It gets the details nearly completely wrong and thoroughly misrepresents things like the optional network-based location used nearly everywhere as Pixel specific.

Any non-Pixel device with the standard Google Play integration has similar Google service integration doing the same things. You don't avoid it at all by using a non-Pixel, but you do end up with a device that's far less secure and adds OEM services with their own privacy issues.

It goes through connections for the Google Play network-based location that's offering as an option during the initial setup wizard, the optional Google Play account-based device management, Google Play feature flags, Google Play telemetry, etc. It gets a lot of details wrong.

iOS has direct equivalents to everything that's covered.

If what people take from the article is that they should use a non-Pixel Android device with Google Play, they'll have a dramatically less secure device with the same privacy issues and additional ones from OEM services.

If what people take from the article is they should use an iPhone instead of a Pixel, they'll have a device with comparable security and similar privacy invasive default connections. iOS does provide better privacy from third party apps than AOSP or the stock Pixel OS, at least.

Unfortunately, the article contributes to people using typical highly insecure Android devices with additional privacy invasive connections, not fewer. If it was promoting iOS over Android, at least it would be helpful overall despite being highly inaccurate. Tech news is awful.

People are having their privacy and security harmed by journalists misleading them because most journalists don't do basic due diligence and simply repeat claims from elsewhere without verification. Many people in the privacy and security communities are doing the same thing.

GrapheneOS is a major security upgrade over the stock Pixel OS or iPhone, but it doesn't mean we're on board with spreading misinformation about either of those. They're the most secure smartphone options and iOS is a clear next best overall choice for privacy after GrapheneOS.

iOS has important privacy features missing in standard Android. Our Storage Scopes feature is needed for parity with iOS. Our Contact Scopes is better than what they added in iOS 18 but it's similar. iOS having better privacy FROM APPS than Android definitely does check out.

The idea that iPhones have better privacy from Apple than Pixels do from Google is largely just a misconception and there's a whole lot of confirmation bias happening. Apple does have better end-to-end encryption support which most users aren't actually enabling for iCloud, etc.

There are a lot of alternative operating systems and supposedly private/secure phone products. Nearly all of these have dramatically worse security than the stock Pixel OS or an iPhone. Nearly all have worse privacy from apps than iOS. They have their own problematic connections.

In terms of privacy from apps, GrapheneOS is competitive with iOS with both advantages and disadvantages. In terms of overall privacy, GrapheneOS is a significant upgrade. Security is a much clearer win for GrapheneOS since Pixels are quite competitive without our work anyway.

Android has useful privacy features unavailable in iOS such as user profiles, Private Space in Android 15, better VPN support, etc. GrapheneOS adds more advantages, and we address the weakness of privacy from apps but not yet to the point it's a clear upgrade in that one area.

Changes in version 129.0.6668.100.0:

• update to Chromium 129.0.6668.100

A full list of changes from the previous release (version 129.0.6668.81.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.

This is an early October security update release based on the October 2024 security patch backports since a monthly Android Open Source Project and stock Pixel OS release based on Android 14 QPR3 hasn't been published yet. Android 15 is scheduled for release around October 15th and they may not have a monthly release based on Android 14 QPR3 before then.

Pixel 4a (5G), Pixel 5 and Pixel 5a are end-of-life and shouldn't be used anymore due to lack of security patches for firmware and drivers. We provide extended support for harm reduction.

Tags:

• 2024100800-redfin (Pixel 4a (5G), Pixel 5)
• 2024100800 (Pixel 5a, 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, emulator, generic, other targets)
• 2024100800-caimito (Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold)

Changes since the 2024092900 release:

• full 2024-10-01 security patch level
• overhaul the implementation of our USB-C port control feature to improve robustness and error reporting
• fix an upstream Android Bluetooth use-after-free bug uncovered by GrapheneOS hardware memory tagging that's triggered when obtaining internet access from another device via Bluetooth
• fix an upstream Android race condition bug in handling of system error files to avoid using the wrong timestamps for system errors and then reporting them as new errors after reboot
• work around an upstream Android bug causing our Log Viewer feature to stop working after system_server restarts
• add handling for early boot-time system journal notifications
• kernel (5.10, 5.15, 6.1, 6.6): backport upstream patch fixing a hole in SELinux W^X enforcement
• kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.226
• kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.167
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.112
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.53
• TalkBack (screen reader): update dependencies
• Vanadium: update to version 129.0.6668.81.0
• GmsCompatConfig: update to version 140

Our understanding is that there will be a stable release of Android 15 on October 15th. We fully ported all our changes to it by September 3rd after the early source code release in September. We'll aim to have a release out within 24h of the stable release being pushed to AOSP.

Today, they published the Android Security Bulletin for October with the security patch backports to the initial releases of Android 12, 12L, 13 and 14. There should be a monthly release based on Android 14 QPR3 today or tomorrow. If not, we'll do a release with the backports.

We've started preparing a release based on the backports in case we need it. One of the patches has major conflicts since these are meant for the initial Android 14 not Android 14 QPR3. It's unfortunate we have to waste resources because they won't share this information with us.

Recent examples where we could have waited if we knew the release date in advance:

August early ASB release: https://grapheneos.org/releases#2024080500

August monthly release: https://grapheneos.org/releases#2024080600

July early ASB release: https://grapheneos.org/releases#2024070200

July monthly release: https://grapheneos.org/releases#2024070201

For months with quarterly and yearly releases, it's common for our early ASB release approach to get those patches to our users days or even weeks early. However, the recent months where they released on Tuesday instead of Monday wasted our time without getting much from it.

Fixing conflicts for the backports can take a lot of time and often requires very skilled work to do it properly as it will for one of the patches this month. Doing an extra OS release also takes a lot of our resources. It takes a lot of local compute time and testing effort.

This shouldn't be something we need to spend resources on because we should know the official release schedule and should have early access. It's harming Android more than GrapheneOS since these kinds of artificial issues inflicted on us are exactly why we stopped contributing.

Changes in version 140:

• update max supported version of Play services to 24.40
• update max supported version of Play Store to 43.0

A full list of changes from the previous release (version 139) 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.

Changes in version 129.0.6668.81.0:

• update to Chromium 129.0.6668.81

A full list of changes from the previous release (version 129.0.6668.70.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.

In April 2024, one of our users did their own testing for VPN leaks on GrapheneOS and discovered multiple issues with the standard Android leak blocking. We've addressed both the network DNS leak when 3rd party VPN apps go down and apps bypassing the VPN via multicast packets.

We've been working on it since April 2024 and have discovered multiple other kinds of leaks. Our latest release addresses all of the known multicast packet leaks, which includes the issue they reported and also 2 more issues we discovered ourselves:

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

We initially shipped our multicast leak blocking in our 2024091700 release but it had to be rolled back due to a severe compatibility issue with IPv6-only networks. Some carriers have IPv6-only mobile data for some or all users with 464XLAT for IPv4 so it's not an edge case.

There were several apps including KDE Connect lacking proper error handling for multicast system calls which were crashing from uncaught exceptions. These apps should be fixed but we need to be compatible with buggy apps so we still would have had to roll back our changes.

DuckDuckGo app has an "App Tracking Protection" which was going into a panic from multicast filtering and spamming enormous numbers of packets which were acting as a DDoS on routers and breaking entire local networks.

Both the IPv6 and app compatibility issues appear resolved.

The issue found by a GrapheneOS user in April 2024 was apps being able to bypass Android's leak blocking by sending multicast packets themselves. We also found other leaks via kernel-generated packets. Our eBPF filter work addresses all of these issues:

https://github.com/GrapheneOS/platform_packages_modules_Connectivity/commit/558cc240147744955d3b4d64e959cd76fc673774

On Android, each user or work profile has their own VPN configuration. Owner user VPN is used for privileged system processes unless they apply special rules for packets.

There are checks to only permit processes sending packets via allowed networks, but we found a hole in it.

We discovered apps can partially bypass these restrictions for VPN tunnels owned by other profiles by using multicast packets. We were unable to figure out an easy way of resolving it with eBPF so we're using netfilter for this part of our leak blocking:

https://github.com/GrapheneOS/platform_system_netd/commit/036d9afd8c3c240fd4ae3a0d2a5059bcaf43fd91

In May 2024, we shipped strict DNS leak blocking to block both the reported leak to network DNS and also leaks to VPN DNS servers outside the tunnel:

https://github.com/GrapheneOS/platform_system_netd/commit/ab1a83dc36e17c4ec61def8cc7386f908e054add

The initial strict approach was reverted before it reached Stable due to VPN app compatibility issues.

We currently use a less strict implementation blocking all leaks to network DNS servers, which fixes what was reported in April 2024 but not everything:

https://github.com/GrapheneOS/platform_system_netd/commit/91caf5c858888cf2dc4bea854e5d3c7ceb2e507a

We're working on a stricter approach that's compatible with ProtonVPN, but it's very hard to test.

There are 2 remaining holes we discovered and don't cover yet:

1. Queries to VPN DNS outside the VPN tunnel
2. Android 14 inbound packet leak blocking is incomplete

We know how to block both kinds of leaks, but we need to be very careful to do it without breaking some VPN apps.

We recently hired the developer who made of our 2-factor fingerprint unlock feature that we'll be shipping shortly after Android 15 is released. They did all of this multicast leak blocking work and are working on fully resolving the remaining 2 already partially resolved issues.

GrapheneOS currently has 6 full-time developers and 1 part-time developer. There are multiple people working as volunteers or who have applied to be hired who we want to hire. Can help us do that with more donations: https://grapheneos.org/donate. We make very good use of the money.

We're very open to helping to get these issues fixed for all Android users. Google simply needs to start treating us fairly and realize collaboration is a 2 way street. We've found more severe bugs than VPN leaks. Ready to help them as soon as this stops:

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

The dates in the thread should all be fixed now. It was meant to say April 2024 and May 2024 but it got mixed up while assembling it and it wasn't noticed until today. It's also fixed at https://discuss.grapheneos.org/d/16161-grapheneos-fixing-the-standard-vpn-leak-blocking-is-nearing-completion/. We unfortunately can't fix it on X and Bluesky beyond adding a reply with a correction.

Pixel 4a (5G), Pixel 5 and Pixel 5a are end-of-life and shouldn't be used anymore due to lack of security patches for firmware and drivers. We provide extended support for harm reduction.

Tags:

• 2024092900-redfin (Pixel 4a (5G), Pixel 5)
• 2024092900 (Pixel 5a, 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, emulator, generic, other targets)
• 2024091900-caimito (Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold)

Changes since the 2024091900 release:

• extend standard Android eBPF filter to prevent apps sending multicast packets outside of the VPN tunnel either directly or indirectly via kernel-generated multicast traffic (IGMP, MLD) when leak blocking is enabled (2nd generation implementation with improved app compatibility)
• add netfilter-based multicast firewall only permitting sending multicast packets to permitted tunnel interfaces for the process to prevent apps sending multicast packets through a VPN tunnel for another profile (2nd generation implementation with improved IPv6 and app compatibility)
• Sandboxed Google Play compatibility layer: add stub for Bluetooth AdvertisingSetParameters.setOwnAddressType() API needed for receiving files through Quick Share
• Sandboxed Google Play compatibility layer: ignore GattServer in BTLeAdvertiser.startAdvertisingSet() needed for receiving files through Quick Share
• Auditor: add battery optimization exception to avoid delays for the opt-in scheduled remote verification since users rarely interact with the app resulting in it being placed into semi-restricted standby buckets
• kernel (6.6): update to latest GKI LTS branch revision
• Auditor: update to version 86
• App Store: update to version 26
• Vanadium: update to version 129.0.6668.70.0
• GmsCompatConfig: update to version 138
• GmsCompatConfig: update to version 139

GrapheneOS users on 8th/9th gen Pixels are making a massive contribution to getting memory corruption bugs in the open source ecosystem thanks to the nice crash report notifications created by our hardware memory tagging feature. One of the latest fixes:

https://github.com/mullvad/mullvadvpn-app/pull/6727/files

Someone should report C.GoString being broken in Go's cgo. Reading an entire page before and after an object that's passed is incredibly broken undefined behavior. They're relying on memory allocation and memory protection having page granularity at a low level which is wrong.

GrapheneOS users have repeatedly found memory corruption bugs in WireGuard-based apps on Android. It's possible most of these are largely caused by memory corruption in the Go runtime because they're playing fast and loose with memory accesses outside the bounds of objects...

GrapheneOS always uses heap memory tagging for every process in the base OS with a single exception (camera HAL). Our implementation is guaranteed to catch all small/linear overflows and even use-after-free until a certain number of allocation cycles for that size class occur.

It has a 14/15 chance to catch any other kind of heap corruption for the standard system allocators.

Since it catches memory corruption as the read or write occurs, it produces very useful tracebacks for devs. We provide them to users with a UI to copy it to report bugs to devs.

Our users on 8th/9th gen Pixels can enable it for all user installed apps via Settings > Security & privacy > Exploit protection > Memory tagging. Use the per-app toggle for incompatible apps and report the bugs to them. It's not used for most user installed apps by default yet.

Apps can mark themselves as compatible with memory tagging to opt-in to having it on GrapheneOS. We also have an app compatibility database where we can add known compatible apps to enable it by default and incompatible ones which skips them with the global default opt-in toggle.

Hardware memory tagging in the security-focused asymmetric mode has very low overhead. Latent memory corruption bugs occurring during regular use in many apps is the only blocker for us enabling it by default for every user installed app as we already do for all base OS apps.

One of the memory corruption bugs in Go being caught by memory tagging on GrapheneOS was reported to Go in September 2018 and is still unfixed today:

https://github.com/golang/go/issues/27610

Reading outside bounds of objects from other languages is a serious memory safe violation, not benign.

Changes in version 139:

• update max supported version of Play services to 24.38
• update max supported version of Play Store to 42.9

A full list of changes from the previous release (version 138) 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.

Notable changes in version 86:

• remove Auditee self-check to avoid most error reporting on the Auditee side to give the Auditor side including our remote attestation service more visibility into why failures are happening
• drop support for obsolete deny new USB setting which was replaced by our newer generation USB-C port and pogo pins not currently accessible to Auditor (a near future GrapheneOS release will add support for the built-in Auditor app reading the new setting and we'll add support for reporting the full set of modes)
• change the High security level to meaning the combination of a StrongBox Hardware Security Module (Pixel 3 and later) and a pairing-specific attestation signing key (Pixel 6 and later for pairings made since we added support for it in June 2022) instead of displaying it as Very High and display only having StrongBox as Standard since every non-end-of-life Pixel has both features
• extend certificate validity for attestation responses by 5 minutes for a total validity period of 15 minutes due to the existing 5 minute leeway before and after
• drop support for earlier protocol versions and raise minimum Auditor version to 73 where the current protocol version was introduced
• modernize code including very minor performance improvements
• update Gradle to 8.10.1
• update Guava library to 33.3.1

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

The Auditor app uses hardware security features on supported devices to validate the integrity of the operating system from another Android device. It will verify that the device is running the stock operating system with the bootloader locked and that no tampering with the operating system has occurred. It will also detect downgrades to a previous version.

It cannot be bypassed by modifying or tampering with the operating system (OS) because it receives signed device information from the device's Trusted Execution Environment (TEE) or Hardware Security Module (HSM) including the verified boot state, operating system variant and operating system version. The verification is much more meaningful after the initial pairing as the app primarily relies on Trust On First Use via pinning. It also verifies the identity of the device after the initial verification. Trust is chained through the verified OS to the app to bootstrap software checks with results displayed in a separate section.

This app is available through the Play Store with the app.attestation.auditor.play app id. Play Store releases go through review and it usually takes around 1 to 3 days before the Play Store pushes out the update to users. Play Store releases use Play Signing, so we use a separate app id from the releases we publish ourselves to avoid conflicts and to distinguish between them. Each release is initially pushed out through the Beta channel followed by the Stable channel.

Releases of the app signed by GrapheneOS with the app.attestation.auditor app id are published in the GrapheneOS App Store and on GitHub. These releases are also bundled as part of GrapheneOS. You can use the GrapheneOS App Store on Android 12 or later for automatic updates. Each release is initially pushed out through the Alpha channel, followed by the Beta channel and then finally the Stable channel.

Notable changes in version 26:

• raise TLS key pinning expiry date
• update Gradle to 8.10.1
• update AndroidX Lifecycle libraries to 2.8.6
• update AndroidX Navigation libraries to 2.8.1
• update Android Gradle plugin to 8.6.1

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

App Store is the client for the GrapheneOS app repository. It's included in GrapheneOS but can also be used on other Android 12+ operating systems. Our app repository currently provides our standalone apps, out-of-band updates to certain GrapheneOS components and a mirror of the core Google Play apps and Android Auto to make it easy for GrapheneOS users to install sandboxed Google Play with versions of the Google Play apps we've tested with our sandboxed Google Play compatibility layer.

GrapheneOS users must either obtain GrapheneOS app updates through our App Store or install it with adb install-multiple with both the APK and fs-verity metadata since fs-verity metadata is now required for out-of-band system app updates on GrapheneOS as part of extending verified boot to them.

Registering on our forum wasn't working for part of September 24th due to a new anti-spam mechanism going wrong. The issue has been resolved now.

https://discuss.grapheneos.org/

If you have any issues with this, please report it in our infrastructure room on Matrix/Discord/Telegram.

Changes in version 129.0.6668.70.0:

• update to Chromium 129.0.6668.70
• rewrite our change for skipping autofill service compatibility checks to resolve a regression

A full list of changes from the previous release (version 129.0.6668.54.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.

No release notes given. Commit history from this release to last release can be viewed here

Pixel 4a (5G), Pixel 5 and Pixel 5a are end-of-life and shouldn't be used anymore due to lack of security patches for firmware and drivers. We provide extended support for harm reduction.

We need more people to use the Beta channel and quickly report regressions in the new releases before they reach Stable. If you're using the Alpha or Beta channels, please join the testing chat room on either Matrix, Discord or Telegram and report regressions in new releases. Our public testing process only works if regressions are reported before the release reaches Stable. For releases with urgent compatibility and security fixes, we try to get it through public testing in 24 hours so we need reports of regressions right away. We've moved 5th generation Pixels to legacy extended support around a month early since we're not getting the feedback we would need to have confidence in shipping the next round of multicast leak blocking for them. They're insecure legacy devices regardless.

Tags:

• 2024091900-redfin (Pixel 4a (5G), Pixel 5)
• 2024091900 (Pixel 5a, 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, emulator, generic, other targets)
• 2024091900-caimito (Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold)

Changes since the 2024091700 release:

• temporarily revert multicast leak blocking firewall due to causing legacy 5th gen devices to lose compatibility with IPv6-only carriers along with causing certain compatibility issues with IPv6 on Wi-Fi
• temporarily revert multicast leak blocking eBPF filter extensions until app compatibility is addressed in a similar way as the Network permission mimics non-security errors

Our latest release blocked a class of VPN leaks via multicast packets discovered by our community. Unfortunately, end-of-life Pixel 4a (5G), Pixel 5 and Pixel 5a have an upstream kernel bug that's causing it to break compatibility with IPv6-only carriers. We're dealing with it.

We're hardly getting any testing feedback for the end-of-life devices which led to this issue slipping into the Stable channel. Our extended support for 5th gen devices will become legacy extended support after Android 15 meaning they won't get these kinds of changes anymore.

Our extended support releases have only ever been planned for the legacy Pixel 5a and earlier with less than 5 years of support from launch. We provide extended support until the first yearly release not supporting them and then switch to a legacy extended support branch.

We likely should have only provided legacy extended support releases via a legacy branch as soon as devices were end-of-life. Extended support encourages people to stick with insecure end-of-life devices and lead to regressions like this but we caught previous ones before Stable.

We're providing one final extended support release for 5th generation Pixels reverting these changes and then they're becoming legacy extended support. This would have happened in October with the stable release of Android 15 regardless, so it makes very little difference.

Separately from this, our multicast leak prevention is causing minor app compatibility issues due to apps trying to use multicast when a VPN is enabled with leak blocking and then not catching the SecurityException which the low-level EPERM error is being converted into for them.

We'll be making a release today reverting our multicast leak prevention for all devices and will begin work fixing the minor app compatibility issues to ship it again.

5th gen will be switched to legacy extended support a few weeks early to work around the old Linux kernel bugs.

Main app compatibility issue is with the DuckDuckGo app's "App Tracking Prevention" feature based on a VPN service. If you use that feature and upgraded to our cancelled 2024091700 release, that's the issue you're having. Likely an app bug, but we'll make sure it works next time.

There may also be compatibility issues with IPv6-only Wi-Fi networks. We're working on resolving this too. We were treating this as security patches and unfortunately we didn't get any reports of any app or network compatibility issues during the 20 hours of public Beta testing.

Pixel 4a (5G), Pixel 5 and Pixel 5a are end-of-life and shouldn't be used anymore due to lack of security patches for firmware and drivers. We provide extended support for harm reduction.

Tags:

• 2024091700-redfin (Pixel 4a (5G), Pixel 5)
• 2024091700 (Pixel 5a, 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, emulator, generic, other targets)
• 2024091700-caimito (Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold)

Changes since the 2024090400 release:

• Sandboxed Google Play compatibility layer: handle the updated client dynamite module initialization sequence
• extend standard Android eBPF filter to prevent apps sending multicast packets outside of the VPN tunnel either directly or separately via kernel-generated multicast traffic (IGMP, MLD) when leak blocking is enabled
• add netfilter-based multicast firewall only permitting sending multicast packets to permitted interfaces for the process to prevent apps sending multicast packets through a disallowed interface such as a VPN tunnel for another profile
• exclude com.android.rkpdapp from backup/restore to avoid breaking key provisioning for hardware key attestation including for Auditor (users can clear RemoteProvisioner system app data via Settings if they restored data for it and have this issue)
• Pixel 9 Fold Pro: temporarily manually add resource overlays not yet automatically handled by adevtool from the stock Pixel OS to use the correct layout for quick settings, status bar, etc. and to provide the split folded/unfolded auto-rotate settings (this will be replaced by adevtool improvements before the end of the month since we'll need it for more resources in Android 15)
• hardened_malloc: fix microdroid virtual machine compatibility by using armv8a+dotprod+memtag when enabling memory tagging instead of armv9+memtag
• init: disable auto-reboot setup for microdroid virtual machines
• expat: backport patches for CVE-2024-28757, CVE-2024-45490, CVE-2024-45491 and CVE-2024-45492 (none of these is exploitable on official GrapheneOS since the DoS bug involves a feature Android doesn't use, the integer overflows require that size_t is 32-bit which is never going to be the case due to the code only being used in 64-bit processes and the negative parameter API issue requires a usage pattern not done by Android, but the integer overflows would be exploitable on an official build for a 32-bit device or a 64-bit device still partially using 32-bit drivers)
• kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.225
• kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.165
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.104
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.51
• TalkBack (screen reader): update dependencies
• Vanadium: update to version 128.0.6613.127.0
• Vanadium: update to version 128.0.6613.146.0
• Vanadium: update to version 129.0.6668.54.0
• App Store: update to version 25
• Auditor: update to version 85
• Info: update to version 4
• GmsCompatConfig: update to version 136
• GmsCompatConfig: update to version 137

Changes in version 129.0.6668.54.0:

• update to Chromium 129.0.6668.54

A full list of changes from the previous release (version 128.0.6613.146.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.

Changes in version 137:

• update max supported version of Play services to 24.36
• update max supported version of Play Store to 42.7

A full list of changes from the previous release (version 136) 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.

Changes in version 128.0.6613.146.0:

• update to Chromium 128.0.6613.146

A full list of changes from the previous release (version 128.0.6613.127.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.