GrapheneOS [Unofficial]

Pixel 4a (5G) and Pixel 5 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:

• 2024040200-redfin (Pixel 4a (5G), Pixel 5)
• 2024040200 (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, emulator, generic, other targets)

Changes since the 2024032100 release:

• full 2024-04-01 security patch level (early release based on AOSP 14 April security backports since the official April AOSP and stock Pixel OS monthly releases aren't available yet)
• fix race condition for Wi-Fi and Bluetooth auto-turn-off leading to the first auto-turn-off timer after the first Wi-Fi or Bluetooth state update potentially not being scheduled
• fix Wi-Fi auto-turn-off no longer handling Wi-Fi state change events not involving a Wi-Fi network
• DocumentsUI (Files): do not delegate handling of downloaded APKs to DownloadProvider to avoid confusing install permission prompt
• flash-all: raise minimum fastboot version to 34.0.5
• kernel (Pixel 8, Pixel 8 Pro): sign vendor modules after building them instead of only signing generic (GKI) modules
• kernel (6.1): update to latest GKI LTS branch revision
• fix upstream bug breaking pressing power button 5 times to make an emergency call
• fix upstream bug causing 5 second delay to start the emergency dialer for the first time
• CarrierConfig2 (app created by GrapheneOS to replace Google CarrierSettings): add stub implementation of VendorConfigProvider
• Setup Wizard: use new API for emergency calls
• Setup Wizard: add prompt for unlocked bootloader triggering reboot to fastboot mode to lock
• Setup Wizard: add prompt for disabling OEM unlocking after the device is locked (will be disabled by default)
• GmsCompatConfig: update to version 100
• GmsCompatConfig: update to version 101
• Vanadium: update to version 123.0.6312.80.0
• Vanadium: update to version 123.0.6312.80.1

Changes in version 101:

• update max supported version of Play services to 24.12
• update max supported version of Play Store to 40.3
• update Gradle to 8.7

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

• backport new Chromium autofill implementation to replace our native Android autofill integration with Chromium's implementation of a choice between browser autofill or app-based autofill with app-based autofill automatically used when the user has activated it

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

Android Open Source Project (AOSP) provides open source infrastructure for device management used to manage enterprise device deployments, kiosks and other situations where a company is considered to own a specific profile or the device as a whole if it's not a personal device.

GrapheneOS has the standard device management infrastructure including the open source Device Lock Controller APEX module.

The only thing we don't implement is preventing someone from wiping the device and using it as a fresh install, since we don't tie devices to accounts.

Recently, a whole lot of misinformation is being spread about GrapheneOS based on this infrastructure being included. The inclusion of the open source code for supporting these use cases does not mean that it's being used. If you don't want it, simply do nothing and it's unused.

Android implements Factory Reset Protection by tying devices to an account and then requiring that account to use the device after wiping it from the recovery mode. This is meant to deter theft but doesn't help you get back your device once someone wipes it and is stuck at login.

We used to prevent wiping without the passphrase, but we realized it was a bad idea and quickly removed it. It led to users bricking their devices. Apple and Google work around this with their standard account recovery, but devices still get bricked including used phone sales.

We've considered providing our own account-based factory reset protection but there's no clear reason to do it beyond spite towards thieves. It won't deter thefts in practice. One person having their device bricked by it would likely hurt our users more than it would ever help...

Companies rely on this anti-theft approach to prevent their employees wiping the devices, stealing them and using them as a personal device.

Device Lock Controller is a specialized form of it to prevent theft by someone that has been loaned a phone but otherwise has control.

We'd have no issue with providing opt-in anti-theft for either an individual owning a device or an organization's fleet of deployed devices. It's simply not as useful as it seems because the device can still be stolen and sold for a lower price than without the feature.

Changes in version 123.0.6312.80.0:

• update to Chromium 123.0.6312.80

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

Google is publicly working on a fix for the factory reset vulnerability we reported:

https://android-review.googlesource.com/c/platform/frameworks/base/+/3008138

Currently, apps using device admin API to wipe do not provide any security against a local attacker since you can interrupt them. Forensic companies are aware of this.

We weren't sure if they would even consider this to be a valid vulnerability but it was accepted as a High severity issue with a $5000 bounty. We also reported what we consider a far more serious firmware vulnerability which received a $3000 bounty due to not having full info.

They're going to be shipping the mitigation we proposed for preventing obtaining data via exploiting vulnerabilities in firmware boot modes in the April security update. We also proposed software improvements which may ship soon. We aren't sure when factory reset will be fixed.

GrapheneOS provides substantial defenses against obtaining data from devices in the After First Unlock state. We recently made major improvements in this area including our new USB-C port control feature able to disable data lines at a hardware level, unlike the standard feature.

Our USB-C port control is set to "Charging-only when locked, except before first unlock" by default. New USB connections can only be made while unlocked, except BFU. After locking, new connections are blocked immediately and data lines are disabled when existing connections end.

We encourage users to use "Changing-only when locked" if they don't need USB devices when the device boots or "Charging-only" if they don't use USB beyond charging. There's also an "Off" value disabling charging when OS is booted into the main OS boot mode for high threat models.

Our auto-reboot feature starts a timer after the device is locked which will reboot the device is it isn't unlocked successfully before the timer elapses. This is set to 18 hours by default but can be set between 10 minutes and 72 hours. It won't chain reboot the device anymore.

Our main defenses against this are our standard exploit protection features:

https://grapheneos.org/features#exploit-protection

Wiping freed memory in kernel/userspace also helps beyond exploit mitigation. We also added full compacting GC for core processes when locking and we're working on much more.

We've planned to support adding a PIN as a 2nd factor for fingerprint unlock since 2016. A new contributor has recently made a lot of progress on it. We'll get it done after duress PIN/password. It will allow using passphrase primary unlock with fingerprint+PIN secondary unlock.

Changes in version 100:

• update max supported version of Play Store to 40.2
• update Android Gradle plugin to 8.3.1

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

Our latest release has been confirmed to resolve Android 14 QPR2 Bluetooth module issues causing connectivity issues with 5th/6th generation Galaxy Watch devices. 2nd set of upstream Bluetooth bugs we've fixed this month. Please provide feedback here:

https://discuss.grapheneos.org/d/11383-request-for-testing-and-feedback-with-bluetooth-on-android-14-qpr2-grapheneos

Pixel 4a (5G) and Pixel 5 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:

• 2024032100-redfin (Pixel 4a (5G), Pixel 5)
• 2024032100 (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, emulator, generic, other targets)

Changes since the 2024031400 release:

• Bluetooth: revert broken upstream change and changes depending on it to fix Galaxy Watch 6 Classic and likely other devices impacted by the same issue (this was a failure of upstream testing and release engineering for AOSP and doesn't impact the stock Pixel OS because it uses a different APEX module revision branched from an older revision of AOSP but it will impact every other Android-based OS on Android 14 QPR2 since there isn't a Bluetooth mainline module published in the Play Store and AOSP yet)
• revert disabling hardened_malloc for Broadcom Bluetooth HAL (we've fixed the upstream issue and this wasn't needed) revert allowing users to disable hardened_malloc for Bluetooth system app (we've fixed the upstream issue and this wasn't needed)
• revert allowing users to disable hardened_malloc for Bluetooth system app (we've fixed the upstream issue and this wasn't needed)
• Android Runtime: disable stripping symbols for libart to restore compatibility with some popular obfuscated Chinese apps using a specific obfuscation SDK depending on private APIs which was broken by Android 14 QPR2 when not using the mainline ART module based on older code like the stock Pixel OS (does not result in any lost storage space, just slightly larger factory images / updates as if we'd bundled another small app)
• Android Runtime: remove Android's hard-wired speed-profile compilation for launcher apps which was limiting ahead-of-time compilation for user installed launcher apps to the parts of the code included in baseline and/or cloud profiles rather than compiling the whole app via our default speed compilation which we use to replace JIT compilation and JIT profiles guiding background AOT compilation
• backport 12 upstream fixes from the mainline MediaProvider, Wifi, NetworkStack and HealthFitness APEX modules
• allow using device controls quick tile when unlocked since it already has a toggle for controlling availability so our new default requirement of the device being unlocked needs to be overridden for it
• more complete setup design configuration to improve appearance of Setup Wizard, etc.
• Settings: fix upstream footer formatting issue for App pinning screen
• update timezone module to Android mainline 341510010 (based on tzdata 2024a)
• kernel (5.15, 6.1): improve support for hosting servers by enabling SYN cookies as we do for the older kernels
• kernel (6.1): drop obsolete usage of YAMA which we replaced with our dynamic SELinux flag extension
• kernel (5.10): update to latest GKI LTS branch revision
• GmsCompatConfig: update to version 99

This series of attacks on Internet infrastructure has made it difficult for some users in Africa and South Asia to download GrapheneOS app and OS releases.

https://blog.cloudflare.com/undersea-cable-failures-cause-internet-disruptions-across-africa-march-14-2024

We have a Singapore location for the website and update server already but not the update servers.

OVH has standard unmetered bandwidth for VPS instances and dedicated servers in North America and Europe but not Singapore or Sydney. It's possible to purchase unmetered bandwidth for a dedicated server but it's insanely expensive. New India DC appears to be a similar situation.

We're looking into our options. Lowest end server in their India DC (Xeon-E 2386G, 32GB memory, 1Gbps) would be around $60/month but then becomes around $550/month for unmetered bandwidth. Peering situation must be awful for Asia considering that's part of base price in EU/NA.

Changes in version 99:

• update max supported version of Play services to 24.10
• update max supported version of Play Store to 40.1

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

Due to mainline modules, the Stock Pixel OS is currently using a much older release of the Bluetooth module than the current release in the Android Open Source Project without current security patches. We believe this is the reason for remaining issues not occurring for stock.

The remaining compatibility issues with a small number of devices such as the past couple generations of Galaxy Watch hardware appear to be the consequence of the March security patches and other changes in QPR2. There's a solid chance the Bluetooth devices are what's buggy.

GrapheneOS is on Bluetooth module version 990090000 from the Android 14 QPR2 release. Stock Pixel OS is still using 341313030, without tags available for that. Needs to be addressed even if simply by tagging the older Bluetooth module release being separately built/shipped.

Tags:

• 2024031400 (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, emulator, generic, other targets)

Changes since the 2024031100 release:

• allow users to disable GrapheneOS hardened_malloc for the Bluetooth system app via the Settings app to help with debugging upstream bugs (still enabled by default)
• temporarily disable hardened_malloc for Broadcom Bluetooth HAL as a potential workaround for upstream bugs in Android 14 QPR2 (will be reverted if it doesn't help and reverted after fixes are implemented if it does help)
• fix upstream bug in Android 14 QPR2 breaking Wi-Fi tethering on fresh installs before Wi-Fi is enabled for the first time, which didn't occur on the stock OS in practice due to it enabling Wi-Fi by default
• fix upstream system_server crash in Android 14 QPR2 when installing updates to packages with an original-package application id such as Vanadium (was reported by users helping with Vanadium Alpha channel testing and we released Apps version 22 with a workaround avoiding the crash prior to this fix)
• Apps: update to version 22
• Vanadium: update to version 122.0.6261.119.0
• Vanadium: update to version 123.0.6312.40.0
• drop legacy script/envsetup.sh (see current build instructions)

Our users have found additional Android 14 QPR2 Bluetooth memory corruption bugs which so far appear to be specific to pairing recent Galaxy Watch devices with GrapheneOS. We're working on finding and fixing this as we did with the BLE audio bugs.

https://grapheneos.social/deck/@GrapheneOS/112066872276203917

The Android 14 QPR2 Bluetooth LE audio bugs we found were fixed in the March 9th release of GrapheneOS: https://grapheneos.org/releases#2024030900.

We also reported it as an Android vulnerability in the same day and it has been initially triaged by them as a High severity and High quality report.

Users on the stock OS are experiencing Bluetooth regressions with Android 14 QPR2 too. These latent and often exploitable bugs breaking functionality for certain users in certain situations often get turned into reliable crashes/breakage due to our memory corruption protections.

The downside is that more of our users get impacted by the issues and they tend to break a specific niche feature completely such as whatever is being used by the Galaxy Watch. On the stock OS, it breaks for some users and may break in a subtle way such as corrupting other data.

The end result is that GrapheneOS users end up with an OS that's not just more secure but has additional bug fixes since our exploit protections force us to fix these issues right after they're introduced instead of remaining dormant breaking things for some users for months.

Changes in version 123.0.6312.40.0:

• update to Chromium 123.0.6312.40

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

Notable changes in version 22:

• skip renamed packages on initial GrapheneOS 14 QPR2 versions due to upstream original-package bug resolved for the next GrapheneOS release (i.e. users who still have an install from before Vanadium was renamed to app.vanadium.browser from org.chromium.chrome will need to wait until the next GrapheneOS release to update it)
• update Gradle to 8.6
• update Kotlin to 1.9.23
• update Kotlin Symbol Processing to 1.0.19
• update Android Gradle plugin to 8.3.0
• update Bouncy Castle to 1.77
• update AndroidX Activity KTX to 1.8.2
• update AndroidX Fragment KTX to 1.6.2
• update AndroidX Navigation libraries and Safe Args plugin to 2.7.7
• update Material Components library to 1.11.0
• update KotlinX Coroutines to 1.8.0
• update AndroidX lifecycle libraries to 2.7.0

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

Apps 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 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 repository 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.

Android is moving towards completing one of the areas of verified boot which currently only works in GrapheneOS. They never fully adopted verifying out-of-band system APK updates with fs-verity and then disabled it. They're moving towards using APK Signature Scheme v4.

Changes in version 122.0.6261.119.0:

• update to Chromium 122.0.6261.119
• extend open external links in Incognito toggle to share intent

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

https://grapheneos.social/deck/@GrapheneOS/112081050753600852

Our recently added low-level USB-C port control feature is now enabled by default. Default mode disables new data connections once the device is locked after the initial unlock. It fully disables the data lines once any existing connections finish.

This is far superior to the standard USB toggle added in Android 12 to the USB HAL and device admin API. That only allows disabling USB at a high level and leaves all the low-level kernel USB driver/protocol and firmware attack surface enabled. It's also simply either on or off.

We also improved the usability of the feature by resetting the USB port when unlocking the device for modes that are charging-only while locked. This causes devices first connected while locked to be detected on unlock. We wanted to address this before enabling it by default.

Our previous USB peripheral control option will likely be removed on devices supporting the new feature, so it will only need to be kept on 5th generation devices. In theory, we could probably implement the new feature for those, but it requires complex device-specific work.

The other major new feature is fully enabling PAC/BTI for userspace on the Pixel 8 and Pixel 8 Pro. Stock OS currently only enables PAC for the kernel where we already enabled BTI to cover functions excluded from type-based CFI. MTE was our priority since it's far more impactful.

We want to enable stack allocation MTE but we need to make sure it works with all of the OS including Chromium's garbage collector stack scanning in Vanadium. Other Chromium-based browsers disable MTE at runtime and Firefox doesn't currently use it, so they don't really matter.

SSP is fully obsoleted by properly implemented stack allocation MTE but the issue is that not everything is compatible with MTE so SSP still needs to be enabled for everything they might use. We have a similar issue with canaries in hardened_malloc which we can't disable yet.

Our features page (https://grapheneos.org/features) needs massive updates to cover everything we've added and changed recently. We'll try to document most of the new major features there in the next few days. It also needs a lot of expansion for the existing features it already covers.

Tags:

• 2024031100 (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, emulator, generic, other targets)

Changes since the 2024030900 release:

• toggle USB port after device unlock to automatically detect a device plugged in while it was in charging-only mode while locked, etc.
• Tensor Pixels: change default mode for our USB-C port control feature able to truly disable USB at a hardware level to "Charging-only when locked, except before first unlock" (doesn't apply to connections that were made before locking or first unlock) which can be changed by users in Settings > Security > USB-C port
• fix Wi-Fi auto-turn-off issues leading to it not triggering in certain cases caused by backwards incompatible changes in Android 14 QPR2
• Pixel 8, Pixel 8 Pro: fix enabling DisplayPort alternate mode support
• Pixel 8, Pixel 8 Pro: fully enable PAC and BTI for userspace too, especially since ShadowCallStack is not currently used in userspace and Clang type-based CFI is only used for a large subset of the important userspace code
• GmsCompatConfig: update to version 98
• improve internal infrastructure used by GrapheneOS features

We're continuing work on integrating ARMv9 security features. MTE is the highest impact and most interesting of these features, but there's less important work to do expanding usage of PAC and BTI. Android uses Clang's type-based CFI but not everywhere so BTI is still useful

Pixel 8 was the first device with a usable MTE implementation despite it launching as part of ARMv8.5. Android world stayed on ARMv8.2 until ARMv9 and Apple hasn't shipped MTE. Apple was a much earlier adopter of the much less useful PAC. From our perspective, PAC was a misstep.

PAC is a weak probabilistic mitigation requiring lots of case-by-case integration. MTE can provide many deterministic guarantees and does a much better job as a probabilistic mitigation by catching memory corruption rather than only protecting specific memory corruption targets.

PAC requires bits which would have been better served by 16-bit MTE support and using a 48-bit address space. Hardware shadow stack is a better backwards edge CFI approach. MTE could be used to mimic hardware shadow stack support via a reserved tag for ShadowCallStack.

We're currently the first platform using userspace heap MTE for hardening in production. We plan to do the same with userspace stack MTE along with doing both in the kernel. Turning ShadowCallStack in the kernel into a hardware protected shadow stack would also be nice to ship.

In the kernel, Pixel OS uses PAC for backwards edge CFI and Clang type-based CFI for forward-edge. We use ShadowCallStack + PAC together and enable BTI in addition to type-based CFI due to lots of functions being excluded from type-based CFI. We plan to do the same in userspace.

Changes in version 98:

• update max supported version of Play services to 24.09
• update max supported version of Play Store to 40.0

A full list of changes from the previous release (version 97) 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 GM's comp at on fig).

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

Tags:

• 2024030900 (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, emulator, generic, other targets)

Changes since the 2024030800 release:

• fix upstream Android 14 QPR2 use-after-free bug impacting Bluetooth LE audio with certain devices (reliably caught by our hardware memory tagging integration on the Pixel 8 and Pixel 8 Pro, but also impacts previous devices which still have the standard hardened_malloc mitigations for use-after-free)
• Settings: hide placeholder dates for Battery information screen in Settings > About device due to 6th/7th generation Pixel batteries having a placeholder value for the first use date

Our hardware memory tagging support for Pixel 8 and Pixel 8 Pro has uncovered a memory corruption bug introduced in Android 14 QPR2 for Bluetooth LE. We're currently investigating it to determine how to fix or temporarily disable the newly introduced feature as a workaround.

Disabling memory tagging for this process isn't an acceptable workaround even in the short term because it's a major attack surface whether or not this particular bug turns out to be exploitable. This only occurs with certain Bluetooth LE devices, not all Bluetooth devices.

We've developed a patch for the upstream Android 14 QPR2 use-after-free bug we discovered with Bluetooth LE. Our priority is getting out a GrapheneOS release with our fix soon and we'll report it as an Android security bug. This should resolve the BLE audio regressions too.

A user able to reproduce the issue with Samsung Galaxy Buds2 Pro in Bluetooth LE mode has confirmed our fix works. This issue also impacts stock Pixel OS. GrapheneOS detects it via hardened_malloc memory tagging support and we added MTE crash notifications with a report to send.

This use-after-free has been reported as a security bug (b/328916844 for Googlers).

Our initial minimally invasive patch:

https://github.com/GrapheneOS/platform_packages_modules_Bluetooth/commit/e295e5888f97ba11a4d07aff3b6bc48b2512831c

This code needs a major refactor and shouldn't be using raw pointers, but we want to avoid introducing new bugs with a quick patch.

Android has ported a lot of the Bluetooth code to Rust. This is a demonstration of why they need to put more resources into porting the rest of the code into Rust.

They should also be testing HWASan and MTE builds with more real world usage including using assorted BT devices.

Pixels shipped a massive hardware security feature (MTE) they aren't enabling for the OS to save 3.125% memory/cache usage. It's silly. Heap MTE has near 0% perf overhead in async mode and is cheaper than increasingly ineffective legacy mitigations like SSP in asymmetric mode.

GrapheneOS enables MTE for the base OS and known compatible user installed apps by default. There's a user-facing opt-in via Settings > Security to turn it on for all user-installed apps. We provide a clear notification with a crash report to copy and a per-app toggle for it too.

We provide a nicer MTE implementation as part of hardened_malloc which uses the standard random tags with a dedicated free tag but adds dynamic exclusion of previous tag and current (or previous) adjacent tags. We also fixed Chromium's integration and will improve PartitionAlloc.

GrapheneOS is the first platform using MTE in production, and does a lot more too:

https://grapheneos.org/features#exploit-protection

Our Vanadium browser is the first browser using it in prod:

https://grapheneos.org/features#vanadium

We plan to add stack MTE, improve PartitionAlloc and make new kernel slab MTE.

This issue was fixed in the March 9th release of GrapheneOS:

https://grapheneos.org/releases#2024030900

We also reported it as an Android vulnerability in the same day and it has been initially triaged as a High severity and High quality report.

We're working on additional reports from users.

GrapheneOS based on Android 14 QPR2 has been heavily tested by our users over the past 2 days and should reach the Stable channel within a few hours.

You can help with final Beta channel testing if you want. The only known regression is Wi-Fi auto-turn-off not always triggering.

Wi-Fi auto-turn-off will be fixed in a near future release. It isn't a release blocker because there are a bunch of important privacy and security patches that are far more important than a minor attack surface reduction feature. You can turn off Wi-Fi yourself for a couple days.