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 I can't find any references about "asymmetric mode" in the context of Stack Smashing Protector, what's this?
@cdc We're referring to MTE in the security-focused asymmetric mode with asynchronous checks on writes and synchronous checks on reads still being higher performance than legacy mitigations like SSP.