Amnesty International’s Security Lab has a post about 3 vulnerabilities exploited by Cellebrite to extract data from locked Android devices. #GrapheneOS blocked exploiting these vulnerabilities in multiple different ways. We also patched them much earlier.

https://securitylab.amnesty.org/latest/2025/02/cellebrite-zero-day-exploit-used-to-target-phone-of-serbian-student-activist/

Each of these is an upstream Linux kernel vulnerability:

* CVE-2024-53104: heap overflow in a Linux kernel USB webcam driver

* CVE-2024-53197: heap overflow in a Linux kernel USB sound card driver

* CVE-2024-50302: uninitialized heap memory in a Linux kernel USB touchpad driver

GrapheneOS blocks reaching any of these vulnerabilities for locked devices through our USB-C port and pogo pins control feature disabling new connections at a hardware level and a software level after locking along with disabling USB data in hardware too:

https://grapheneos.org/features#usb-c-port-and-pogo-pins-control

CVE-2024-50302 is benign on GrapheneOS. For both the kernel and the rest of the OS, we use the combination of use zero-on-free and either zero-on-allocate or a write-after-free check at allocation time. On devices with hardware memory tagging (MTE), it's done as part of tagging.

CVE-2024-53104 and CVE-2024-53197 are both kernel heap overflows in slab allocations. We provide improved defenses against these attacks in multiple ways covered in the kernel section at https://grapheneos.org/features#exploit-mitigations. Our defenses in userspace are far stronger due to hardened_malloc.

We recently enabled hardware memory tagging (MTE) for Linux kernel after over a year of deploying it for userspace via hardened_malloc. It provides an approximation of memory safety which can be improved over time. It requires hardware support exclusive to 8th/9th gen Pixels.

GrapheneOS shipped patches for these 3 vulnerabilities significantly before the stock Pixel OS or inclusion in an Android Security Bulletin through shipping the latest Linux kernel GKI LTS releases. However, what really matters is we prevented them being used before discovery.

We have a recent post at https://grapheneos.social/@GrapheneOS/113961075324902277 covering how we've significantly improved our defenses against forensic data extraction since January 2024. It covers a lot more than what we talked about here and we recommend reading it along with our features page covering more.

Reply to this note

Please Login to reply.

Discussion

Solid work guys!

I really enjoy these reports. It would be nice to know when exactly these security holes were patched on stock android though.

The Android Security Bulletin tells you of CVEs that get uncovered and patched in Android. They'll also link the commits that patch them.

In this case example only CVE-2024-53104 was patched and it happened this month.

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

CVE-2024-53197 and CVE-2024-50302 have been patched upstream in the Linux kernel but have not yet been in Android. It doesn't effect GrapheneOS due to the security features and us updating Linux kernel Generic Kernel Image (GKI) every time there's a new revision rather than Google only doing it quarterly or less and only backporting patches in special cases.

Because of that, many upstream kernel vulnerabilities are available in Android but not GrapheneOS, we talk about that on the site here:

https://grapheneos.org/features#more-complete-patching

I talked about CVE-2024-53014 prior here, we patched this vulnerability months prior thanks to earlier and complete kernel patching, appears to be December. We were pretty right on the money with what our assumption this vulnerability was being used for and by who.

nostr:nevent1qqs9ayl7tq5zp0vmhmjysn0q3lq4kyjg59yeeykfrkr9q6c2kyuy5lqpzpmhxue69uhkummnw3ezumt0d5hsyg9e3hk5e6h2ypusm09ncv2qq6fqp8f5clueylpgdq66nxm5sxjuygpsgqqqqqqsxnchny