# A Recursion Bug That Could Compromise an Android Phone

As developers, we have all seen bugs caused by recursion.

When recursion goes out of control, we usually expect something simple:

**Stack overflow → application crashes → fix the bug.**

But what if that stack overflow happens inside a phone's **baseband processor**?

And what if specially crafted network data can trigger it remotely?

That is where this UNISOC baseband vulnerability gets very interesting.

The vulnerability shows how a programming problem that looks simple at first — **uncontrolled recursion** — can turn into memory corruption, code execution, and potentially a much bigger compromise.

So let's break down how that happens, starting from the developer side and slowly moving into the security side.

## First, This Is Not a Normal Android App Bug

When we think about Android security, we normally think about Android itself or the applications installed on the phone.

But there is another important part of the phone:

**The baseband processor.**

It handles communication between the phone and the cellular network.

When a VoLTE call is established, protocols such as **SIP** and **SDP** are involved.

In simple terms:

**SIP → helps establish the communication session**

**SDP → describes how that session should work**

The interesting part starts when the baseband parses this data.

## Where Does Recursion Come In?

Inside the SDP parsing logic described in the vulnerability, processing a particular field could cause the same processing logic to be called again.

And again.

And again.

Something like:

```text
parse()
 └─ parse()
     └─ parse()
         └─ parse()
             └─ parse()
                 ...
```

There is no proper stopping point.

Every function call needs some memory on the **stack**.

So as the function keeps calling itself, the stack keeps growing.

From a normal developer's point of view, we might expect:

**Stack grows → stack overflow → crash**

But this is where the security side becomes much more interesting.

## What If the Stack Grows Into Something Else?

The baseband runs in an embedded environment using an **RTOS — Real-Time Operating System**.

This is not exactly like running two normal applications as separate, isolated processes on your computer.

Tasks can exist inside a shared memory space.

A simplified view could look like this:

```text
┌─────────────────────┐
│ SDP Parser Task     │
│                     │
│ Stack grows ↓       │
│ ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓     │
├─────────────────────┤
│ Another Task        │
│                     │
│ Function pointers   │
│ Other data          │
└─────────────────────┘
```

Now imagine that uncontrolled recursion keeps growing the stack beyond the memory area it should use.

It can start corrupting memory belonging to another task.

Now this is no longer just:

**“The application crashed.”**

If useful data inside the other task can be overwritten, things can become much more serious.

One important target is a **function pointer**.

A function pointer basically tells the system where a function is located in memory.

If an attacker can overwrite it with an address they control, they may be able to change where the program executes next.

So now the chain becomes:

```text
Malicious network input
        ↓
Uncontrolled recursion
        ↓
Stack overflow
        ↓
Memory corruption
        ↓
Function pointer overwrite
        ↓
Code execution
```

A recursion bug has now become a security vulnerability.

## Why Does Baseband Code Execution Matter?

Getting code execution inside a **baseband processor** is already serious.

The baseband handles some of the most important communication happening on a phone.

But there is another interesting part.

The baseband processor and the phone's main processor need to communicate.

There can be trust and shared resources between these components.

If a compromised baseband can access sensitive memory belonging to the main processor, an attacker may potentially move further toward something much more powerful:

**the Android kernel.**

So at a high level, the attack chain looks like this:

```text
Network / phone communication
          ↓
Crafted VoLTE signaling
          ↓
SIP / SDP parsing
          ↓
Uncontrolled recursion
          ↓
Stack corruption
          ↓
Baseband code execution
          ↓
Potential Android kernel compromise
```

And the interesting thing is where all of this started:

**Recursion.**

## The Developer Lesson I Find Most Interesting

This vulnerability is a good example of why security is not only about finding things like XSS, SQL injection, or authentication bugs.

Sometimes the starting point is a normal programming mistake.

A recursive function.

A parser.

Missing validation.

A wrong memory assumption.

The important question is **where that mistake exists and what an attacker can do with it.**

When we find something that crashes, the first question is naturally:

**“Why did it crash?”**

But from a security point of view, there are more questions worth asking:

**Who controls the input?**

**What happens to memory when it crashes?**

**What exists next to that memory?**

**What permissions does this component have?**

And probably the most interesting one:

**What other components trust it?**

A crash is not always just a crash.

Sometimes it is the first step toward something much bigger.

And this UNISOC baseband vulnerability is a very good example of that difference between simply seeing a programming bug and looking at the same bug through a security researcher's eyes.