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.

fix use-after-free for sink/source metadata · GrapheneOS/platform_packages_modules_Bluetooth@e295e58

This uses malloc/free to work around the existing code using a raw pointer to avoid invasive changes.

GitHub

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.

GrapheneOS features overview

Overview of GrapheneOS features differentiating it from the Android Open Source Project (AOSP).

GrapheneOS
@GrapheneOS why can't hardened_malloc replace PartitionAlloc?
@idkrn @GrapheneOS PartitionAlloc is deeply integrated into the browser and is responsible for type sequestering between different objects types in the browser; I don’t see a path where this can be done without losing a lot of the protection against type confusion with DOM objects
@duckie just seemed like the MTE benefits etc. could be worth it