Since this month’s release of Android isn’t available yet, we’re currently building/testing an early March security update release providing the Android Security Bulletin backports of High/Critical severity patches. Android 15 QPR2 will be available in the near future though.

March security bulletin lists 2 vulnerabilities as actively exploited in the wild:

https://source.android.com/docs/security/bulletin/2025-03-01

CVE-2024-43093 patch was in Android 15 QPR1 released in December. It’s just being backported now.

CVE-2024-50302 doesn’t impact GrapheneOS due to our exploit protections.

Android Security Bulletins are very commonly misinterpreted as being Android’s monthly security patches. They’re actually backports of most High and Critical severity patches to older releases of Android: 12, 12L, 13, 14 and 15. Yes, Android 15 is an older release of Android.

CVE-2024-50302 is one of 3 vulnerabilities which Amnesty International recently found being exploited by Cellebrite. This one was fully eliminated as a bug in GrapheneOS through zeroing. Separately from that, our USB-C port control blocked reaching any of the 3 bugs while locked.

For more details on the 3 Linux kernel USB bugs exploited by Cellebrite, see our thread at https://grapheneos.social/@GrapheneOS/114081753914226921. GrapheneOS blocked reaching all 3 while locked at both a hardware and software level, eliminated one and made the other 2 much harder to exploit even when unlocked.

They included one in the February security bulletin, another this month and still need to add CVE-2024-53197. We patched all 3 earlier via the kernel.org LTS revisions. Our exploit protections blocking exploiting them prior to patching is the far bigger difference.

March security bulletin lists 9 Critical severity Bluetooth vulnerabilities caused by use-after-free bugs. Our hardened_malloc project provides strong protections against exploiting these, especially on Pixel 8 and later where it has very good hardware memory tagging integration.

When a memory allocation of 128kiB or below is freed on GrapheneOS, memory tagging gives it a dedicated tag detecting any invalid access. It goes through a random quarantine and first-in-first-out quarantine before reuse. First reuse is guaranteed to use a different random tag.

Memory tagging also zeroes the allocation. On devices without it, we still zero it at free time and then check for the zeroing at allocation time to detect write-after-free and guarantee that fresh allocations are zeroed. With memory tagging, it detects the invalid accesses.

After a memory allocation is freed, goes through both quarantines, is allocated again, freed again, goes through both quarantines and is allocated again there’s still a 14/15 chance for the random tag to detect an invalid memory access. Attackers also usually need to chain bugs.

GrapheneOS users have been regularly finding obscure Bluetooth memory corruption bugs with specific accessories. We generate user-facing notifications for MTE detecting invalid accesses for users to report to us and app devs. We can likely close several more of those issues now.

We’ve actually had these Critical severity Bluetooth patches backported for a month already:

https://github.com/GrapheneOS/platform_packages_modules_Bluetooth/commits/69d9332c8d7097ecece3b94bcd506739e4e5a54b/

Good news is that we’ve already had those patches for a month. Bad news is it’s not the reason for the remaining issues being caught by MTE, will need more work.

“Fix UAF in sdp_discovery.cc” patch was included upstream previously, it’s just a backport. The others we applied ourselves last month. They weren’t listed in the bulletin or included in the monthly update but they were published and they did fix some issues we’d caught with MTE.