A Video Call Gets You Kernel Access on Unisoc Phones

The Unisoc bug that landed on August 17 is worth understanding at the hardware level, because the fix is not a patch anyone can ship quickly. On affected Unisoc systems-on-chip, the modem processor and the application processor share one physical memory space, and nothing in hardware stops code running in modem context from writing into kernel memory. Get execution on the modem and you are not sandboxed anywhere. You are simply inside the phone.

SSD Secure Disclosure published that second stage this week, credited to an independent researcher using the handle 0x50594d. It completes a chain that started in March 2026, when the same team disclosed remote code execution in Unisoc modem firmware through a malformed SIP video call. Stage one gets you onto the modem. Stage two, new this week, escalates from the modem to full Android kernel access. The classification is CWE-1189, improper isolation of shared resources on a system-on-a-chip, and that phrase is doing a lot of work.

RelatedAirDrop and Quick Share Flaws Expose Billions of Phones

How does the escalation actually work?

Once an attacker holds code execution in modem context from stage one, the escalation writes a full-access configuration into the ARM Memory Protection Unit through coprocessor registers. That maps the entire 32-bit physical address space as readable, writable and executable. Every protection that was supposed to keep the baseband away from the application processor stops applying, because the component enforcing those protections has been reconfigured by the thing it was meant to contain.

This is the part most coverage skips. The baseband processor on a modern phone runs its own closed firmware and has historically been treated as a separate trust domain from Android. The entire security argument for that arrangement rests on a hardware boundary between modem memory and kernel memory. On these Unisoc parts that boundary is configurable from the modem side, so it is not really a boundary. It is a suggestion.

What does an attacker need to pull this off?

More than you might fear, and less than you would like. Three things: a modem-level foothold from the stage-one RCE, control of a private 4G cellular network, and a victim who answers the incoming video call. Standing up a private 4G network is not a trivial hurdle, but software-defined radio has made it a hardware-budget problem rather than a nation-state problem.

The user interaction requirement is real but weak. The victim only has to answer what looks like an ordinary video call. There is no attachment to open, no link to tap, no permission dialog to approve. From the user's side the attack surface is a ringing phone.

That combination puts this squarely in the targeted-attack bucket rather than the mass-exploitation bucket. Nobody is scaling a private 4G network against millions of handsets. Someone operating in a defined physical area against specific people absolutely can.

Which devices are affected?

SSD lists four Unisoc parts, and the device names attached to them explain why this matters more than the raw exploit complexity suggests. These are not flagship chips. They are the silicon inside entry-level phones sold in enormous volume across India, Southeast Asia, Africa and Latin America, plus at least one automotive part.

The Redmi A5 result is the one that should bother you. It was tested on a January 2026 security patch level, which is to say a phone that was patched recently by the standards of the budget Android market and still fell to the chain. Monthly Android security bulletins do not reach modem firmware. That code ships from the silicon vendor through the handset maker, and on budget devices it frequently never ships again after launch.

RelatedA Windows Socket Driver Bug Handed Lazarus SYSTEM Access

Why is there no fix?

Because the vendor has not engaged. SSD's advisory states plainly that the team tried to reach Unisoc through multiple channels including email and LinkedIn and received no response. There is no patch, no advisory from Unisoc, and no CVE assigned to the privilege-escalation stage as of publication. The related October 2025 modem input-validation flaw, CVE-2025-31718 at CVSS 7.5, does have an identifier, which shows the process can work when someone picks up the phone.

The structural problem is that fixing this properly is a hardware change. You can patch the SIP parser that gets you onto the modem in the first place, and that would break the current chain. You cannot patch away a missing memory boundary between two processors on a die that has already shipped. Every future modem bug on these parts inherits the same escalation path.

1. Oct 2025CVE-2025-31718 disclosed modem input validation, CVSS 7.5
2. Mar 2026Stage one: RCE via malformed SIP video call code execution in modem context
3. Aug 17Stage two: escalation to Android kernel MPU reconfigured from modem
4. OpenVendor response and patch Unisoc has not replied to researchers

What should you actually do?

For most readers, very little, and that is an honest answer rather than a reassuring one. The prerequisites keep this out of opportunistic crime. If you carry one of the listed devices in a context where targeted surveillance is a genuine concern, the practical mitigation is to disable VoLTE video calling where your carrier and handset allow it, since the entry point is the video call path specifically. Turning off VoLTE entirely will drop you to 3G or 2G on many networks, which trades one set of risks for another.

For anyone running a fleet, the useful action is inventory. Find out which Unisoc parts are in your device estate, including any vehicle head units, and treat those devices as having a permanently weaker baseband boundary than their Android patch level implies. That is a procurement input more than an incident-response one.

Original analysis by GenZTech, built from SSD Secure Disclosure's two advisories and the CWE-1189 weakness definition. Chain first reported by The Hacker News.