Technical writeup analyzing CVE-2024-20154, a stack-based buffer overflow in MediaTek MT6769 NB-IoT baseband firmware, covering reverse engineering and exploitation chain.
Classification: CWE-121 — Stack-based Buffer Overflow
Severity: Critical (MediaTek bulletin) · 8.8 High, Attack Vector: Adjacent (CISA-ADP)
Type: Remote Code Execution — no user interaction, no prior association
Disclosure: MediaTek Security Bulletin, January 6, 2025 https://corp.mediatek.com/product-security-bulletin/January-2025
Analyzed target: Samsung Galaxy A14 SM-A145R — MT6769 family (Helio G80), within MediaTek's affected chipset list - Firmware was emulated under safe conditions.
Status: Patched.
This was my first published baseband research. I come from a background far away from telecoms infrastructure, lawful interception mediation layers, stingray and IMSI-catcher analysis, and embedded device security — I had not previously done deep firmware reverse engineering on a cellular modem. I wanted to prove to myself that a structured analytical methodology adapts across targets, and that familiarity with a specific platform can be replaced by rigorous chain-tracing. NB-IoT stood out because it sits at a genuinely dangerous intersection: the protocol is designed for constrained IoT devices, the attack surface is pre-association, and the modem stack processes it regardless of what the handset user is doing.
When the patched firmware was analyzed and the vulnerable pattern confirmed absent, the AI system used for mass analysis of the firmware before targeting specific functions
independently matched the reconstructed bug class, conditions, and affected firmware family to the description of CVE-2024-20154.
The technical conclusions are the analyst's own.
The phone in your pocket contains at least two separate computers. The one you interact with runs Android. The other — the baseband — runs completely independently, handles all radio communication, and is almost entirely invisible to the operating system above it. Android may be fully patched. The browser may be sandboxed. The user may never tap a malicious link. None of that matters if the vulnerable code is in the modem firmware that processes radio signals before the application processor is involved.
CVE-2024-20154 is exactly that kind of vulnerability.
A malformed NB-IoT system-information broadcast causes the MediaTek modem firmware to accept an attacker-controlled scheduling count, carry that count through the RRC-to-L1 configuration path without ever clamping it, and eventually use it as the loop bound for a stack-writing loop inside the NB-IoT broadcast-channel handler. When the count exceeds the destination arrays' capacity, the loop writes past them, reaches saved registers on the stack, and overwrites the saved return address. The function then restores the corrupted value into the return-address register and jumps to it.
What makes the severity what it is:
The vulnerability was published in MediaTek's January 6, 2025 Security Bulletin with a Critical severity rating, affecting the LR12A modem family among others. Samsung incorporated the fix into their February 2025 Security Maintenance Release.
This post does not publish a weaponized exploit and is not reproducible from what is published here. The goal is to show where the chain breaks, why each layer failed to stop it, and what it takes to validate a baseband bug responsibly when you cannot attach a debugger to the live modem.
Primary target: Samsung Galaxy A14 (SM-A145R). The radio subsystem is driven by a MediaTek baseband processor in the MT6769 chipset family (Helio G80). The MT6769 family is explicitly listed in MediaTek's affected chipset list for CVE-2024-20154.
AP/CP firmware: A145RXXU1AWD1
Modem software: MOLY LR12A.R3.TC10.6M.A14.PR.SP.V1.P5
Build date: 2023-04-18
The baseband firmware is not Android code. It is a separate embedded system on the radio subsystem of the SoC with its own CPU, its own RTOS, and its own memory space, outside the Android process sandbox.
Analysis of the extracted binary shows the modem processor runs MIPS32 with MIPS16e2 compressed instructions in little-endian mode. MIPS16e2 is a 16-bit encoding extension for embedded code-size reduction — consistent with MediaTek's approach for Helio-generation basebands, confirmed by independent published baseband research on this SoC family.
The operating system is Nucleus RTOS, providing task scheduling, IPC message queues, and a pool-based memory allocator. There is no kernel/user privilege separation, no memory protection unit enforcement between tasks, and no hardware stack-guard mechanism.
All addresses in this post are virtual addresses, as loaded in Ghidra at base 0x90000000.
| Mitigation | Status | Effect |
|---|---|---|
| ASLR | Absent | Firmware addresses are static and predictable from the image |
| Stack canary | Absent | SAVE/RESTORE stores callee-saved registers with no guard value |
| NX / W^X | Absent | Stack memory is executable |
| CFI | Absent | Return addresses are not validated against any policy |
Three parallel tracks:
Static analysis. Samsung firmware package → CP partition extraction → md1img.img →
Ghidra (MIPS LE 32-bit, base 0x90000000) with MediaTek engineering symbols recovered from
the firmware debug section using the NCC Group mtk_bp toolset.
Dynamic validation. Unicorn Engine (MIPS32 emulation) was used to execute specific
firmware routines in isolation across two phases. Phase 1 attempted to prove the unclamped
copy of si_count into channel context through the native instruction pair. Phase 2 executed
the vulnerable loop on real firmware bytes and confirmed that the firmware's own instructions
corrupt the saved return address. Where Phase 1 could not run fully natively — because the
RTOS service-object environment required by the CPHY dispatch path was not reconstructed —
the side effect was modeled directly and labeled as such in all output.
Radio-side validation. srsRAN 4G with a ZMQ loopback — software-only, no RF emission — confirmed that the test payload survives NB-IoT PHY encoding and transport-block delivery.
NB-IoT (Narrowband Internet of Things) is 3GPP Release 13, designed to connect constrained IoT devices using existing licensed LTE spectrum. It is implemented in a wide range of modern cellular SoCs including those in consumer smartphones.
While in RRC_IDLE, before any RRC connection is established, a device searching for service will:
At step 3, the modem processes a message from an entity it has not authenticated, before any connection or user interaction. A rogue transmitter satisfying normal cell selection conditions will be processed.