February 2025 Android Security Bulletin includes a heap buffer overflow in a Linux kernel USB peripheral driver (CVE-2024-53104) marked exploited in the wild. It's likely one of the USB bugs exploited by forensic data extraction tools. We block them using these.
https://source.android.com/docs/security/bulletin/2025-02-01
By default, GrapheneOS blocks new USB connections when the device is locked in the Linux kernel and at a lower level via the USB-C and pogo pins controllers to defend the firmware and lower-level Linux kernel code too. Data is blocked in hardware once connections end.
https://grapheneos.org/features#usb-c-port-and-pogo-pins-control
If a user connected a malicious USB device while unlocked which tried to exploit this, general purpose exploit protections come into play. For the majority of the OS, our hardened_malloc project provides strong protections against heap corruption exploits. Kernel heap hardening is a separate thing.
One of the stronger defenses in hardened_malloc is our own implementation of hardware memory tagging (MTE) which integrated shortly after it shipped in production with the Pixel 8 (https://grapheneos.org/releases#2023103000) and we had it enabled by default in around a month (https://grapheneos.org/releases#2023110700).
Linux kernel has a standard disabled by default implementation of hardware memory tagging. We very recently began enabling to defend it from issues like this USB heap corruption vulnerability (https://grapheneos.org/releases#2025011500). It's a major improvement but still not nearly as good as hardened_malloc.
We also already had CVE-2024-53104 patched prior to this month since we ship the kernel.org LTS revisions long before the Android Open Source Project / stock Pixel OS. Our systemic defenses are far more important because they work before vulnerabilities are known, so we didn't lead with that fact.
Many people have the misconception that security is about patching vulnerabilities. That's the bare minimum. Security should to be part of the design and implementation from the beginning. Linux kernel is an example where that wasn't the case at all and it's hard to provide it.
Linux kernel is a large monolithic kernel, meaning it has no internal isolation. All of the code including obscure drivers enabled in the build have access to everything it does. It's almost entirely written in C, a memory unsafe language where many tiny mistakes are code execution vulnerabilities.
Linux kernel is currently a major weak point for Android's security. It's the easiest way out of both the app sandbox and the more constrained sandboxes used for Android media processing and Chromium renderer processes. The Linux kernel is also a major physical and remote attack vector itself.
Android is moving towards writing new Linux kernel device drivers in Rust to prevent most of these vulnerabilities. We'll leave that to them and will be focusing on deploying better exploit protections and more heavily using hardware-based virtualization for better sandboxing than Linux can provide.