I can't TLDR this as we reported this, but it is good news. We discovered this and took action in January.

If you mean the first vulnerability in the article (CVE-2024-32896) then we reported that vulnerability ourselves. Its the 2nd part of the fix for CVE-2024-29748 vulnerability we described here:

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

Despite the nomenclature of this type of vulnerability, this is not actually Pixel specific. The two CVEs refer to a same vulnerability of interrupting reboot for wipes via the device admin API, which applies to all devices.

CVE-2024-32896 is a full fix in AOSP as part of Android 14 QPR3 where the device can now be wiped without a reboot. It's not specific to Pixels at all. CVE-2024-29748 was a mitigation for the issue implemented in the Pixel bootloader although it doesn't entirely address the problem.

These vulnerabilities were discovered by us as a forensics company (MSAB) were selling Brute Force capabilities for Pixels on the Stock OS and leaked how they were doing it in an instruction video about bypassing insecure duress apps like Wasted using the device admin API to factory reset (CVE-2024-29748). We understood that they would boot into fastboot mode to interrupt factory resets helped by the device not wiping without reboot (CVE-2024-32896), which led them to RAM dump (CVE-2024-29745) and brute force the device from the credential hashes left in memory to unlock the device.

MSAB openly admitted they weren't able to do this with GrapheneOS. Since they could only do this on an AFU device then our automatic reboot feature stopped them there too. Hardened_malloc (hardened memory allocator used in GrapheneOS) zeroes memory when free which could also have played a factor.

MSAB discussed having consent support (which involves user giving away their PIN/password consensually) for their forensic extraction software for GrapheneOS but that's not relevant to us. The targets were strictly stock OS users, but that doesn't mean adding these fixes didn't help GrapheneOS too, and we would never say never to something similar happening for GrapheneOS devices even with that confirmation.

We took additional action and added features like USB-C port controls, duress password. and hardening against proximity attacks. We added firmware-based reset attack mitigations as part of GrapheneOS device requirements afterwards. Other OEMs have this issue and they need to fix it themselves.

The other CVEs mentioned were fixed back on April for stock OS users. Although the reason this came up again this week is the full solution to this is implementing wipe-without-reboot, which is now a standard feature in Android 14 QPR3 released as part of AOSP released a few days ago. GrapheneOS upgraded to Android 14 QPR3 as it came out, but we backported the wipe-without-reboot on 2024052100 for our unique duress password feature.