UNISOC T612 RCE March 11, 2026 SSD Secure Disclosure technical team Vulnerability publication Summary UNISOC (Shanghai) Technologies Co., Ltd. is a top-three global fabless semiconductor company headquartered in Shanghai, specializing in 2G/3G/4G/5G mobile communication, IoT, and smart device chipsets. Formerly Spreadtrum, it serves major brands like Honor, realme, vivo, Samsung, and Motorola, with products in over 140 countries. A critical vulnerability has been discovered in the UNISOC modem firmware that enables one User Equipment (UE) to remotely attack another UE over the cellular network. By sending specially crafted malformed SDP within SIP signaling messages/requests, an attacker can trigger memory corruption in the target modem, potentially leading to remote execution of arbitrary native code on the victim device. Vendor Response We have tried to reach out to the vendor through multiple channels (email and LinkedIn) but have not been able to receive any response. Credit The vulnerabilities have been discovered by, an independent security researcher 0x50594d, working with SSD Secure Disclosure. Affected Versions MOCORTM_22A_W23.02.5_P12.14_Debug (part of Realme C33) T612, T616, T606 and T7250 Vulnerability Details An exploitable Uncontrolled Recursion ( CWE-674 ) was identified in the modem’s handling of SDP messages. The root cause lies in unsafe parsing logic inside the _SDPDEC_AcapDecoder function, which fails to properly validate message fields before processing. Root cause analysis The function _SDPDEC_AcapDecoder is responsible for handling the acap attribute. After parsing the attribute’s value, the function retrieves the name of the next attribute. It then looks up this attribute in the SipHandler_AttrDecoder table. If the attribute is recognized, the appropriate handler is invoked. undefined8 _SDPDEC_AcapDecoder(Token *token,ParseBuffer *parse_buffer,SdpMsgStruct *hSdpMsg) { char cVar1; int iVar2; undefined4 uVar3; char *pcVar4; int iVar5; sipHandlerFunc *handler; int iVar6; int local_30; SdpMsgStruct *handler_id; undefined1 error [4]; iVar6 = token->field3_0x14; local_30 = 0; handler_id = hSdpMsg; display_sip_message(0x200,"_SDPDEC_AcapDecoder: hSdpMsg:%X hAttr:%X",hSdpMsg,iVar6); *(undefined2 *)(iVar6 + 0x14) = 1; iVar2 = (*(code *)token->handlerGetToken)(token,parse_buffer," "); if (iVar2 == 1) { if ((token->CurrToken).length != 0) { uVar3 = strtoll((token->CurrToken).pStart,error,10); *(undefined4 *)(iVar6 + 0x18) = uVar3; iVar2 = (*(code *)token->handlerGetToken)(token,parse_buffer,":\r\n"); if (iVar2 == 1) { iVar2 = search_handler(&token->CurrToken,SipHandler_AttrDecoder,0x38,&handler_id); // get appropriate handler -- SNIP -- handler = SipHandler_AttrDecoder[(int)handler_id].handler; token->currentHandlerExecution = handler; if ((handler == (sipHandlerFunc *)0x0) || (cVar1 = (*handler)(token,parse_buffer,(int)hSdpMsg), cVar1 == '\x01')) { // handler invoked iVar5 = *(int *)(iVar6 + 0x1c); if (iVar5 == 0x2b) { The SipHandler_AttrDecoder table is presented below. It can be observed that the acap attribute is included in the table. 8d0f25c0 44 9e e1 SipHandler_AttrDecoder 8b 0b 00 00 00 87 8d0f25c0 44 9e e1 8b 0b SipHandler [0] = "rtpmap" 00 00 00 87 ff c8 8b 8d0f25cc 4c 9e e1 8b 0c SipHandler [1] = "cat" 00 00 00 95 fd c8 8b // -- SNIP -- // 8d0f280c 80 a0 e1 8b 3d SipHandler [49] = "acap" 00 00 00 c3 15 c9 8b This is problematic because the _SDPDEC_AcapDecoder function can recursively call itself without any limit. An input containing multiple acap attributes on the same line will cause the SIP task’s stack to collide with the sblock_0_2 task’s stack. Bellow SDP poc that will trigger the stack overflow : v=0 a=acap:1 acap:1 acap:1 acap:1 acap:1 acap:1 acap:1 acap:1 [...] acap:1 It is possible to trigger an overflow in the sblock_0_2 task, but it is now necessary to ensure that this task is activated so that our stack overflow affects it. After analyzing the kernel code of the RealmeC33 , it appears that this task is activated whenever data fragmentation occurs in the IMS context. SRTP packets will cause data fragmentation. Consequently, a simple video call initiated by the attacker will fragment the data and therefore trigger the sblock_0_2 task and then crash. Code execution can be induced as the overflow in the sblock_0_2 task overwrites function pointers. For the purposes of this analysis, a separate attribute – the crypto attribute – was used to introduce controlled data onto the stack. Exploit Test Environment Setup For testing purposes, the Docker-based Open5GS deployment with Kamailio was used. The Dockerized VoLTE Setup tutorial was used as a reference. Victime phone The victim’s phone used in this test is the following: Mobile Realme C33 (Unisoc T612) Android security update 1 jully 2025 It is possible to root the phone by using the following repository . Attacker phone An attacker could use any smartphone to contact the victim, requiring only the ability to place a video cal...