CVE-2026-104591 in libosmocore
Summary
by MITRE • 10/26/2026
libosmocore through 1.14.1 contains a buffer overflow in osmo_iuup_compute_payload_crc() in src/gsm/iuup.c. This allows a remote attacker to cause a denial of service.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified within libosmocore versions up to and including 1.14.1 represents a critical memory safety failure located specifically within the osmo_iuup_compute_payload_crc function found in the src/gsm/iuup.c source file. This component is integral to the Open Source Mobile Communications project, which provides essential libraries for implementing GSM and UMTS network protocols. The specific flaw arises during the computation of cyclic redundancy checks (CRC) for IU-UP protocol payloads. In this context, the function processes incoming data streams that are part of the signaling interface between base stations and core network elements in mobile telecommunications infrastructure. When processing these payloads, the implementation fails to adequately validate buffer boundaries or input lengths before performing memory write operations, leading directly to a heap-based buffer overflow condition.
From a technical perspective, this is classified under CWE-120, which denotes Buffer Copy without Checking Size of Input. The root cause lies in the lack of rigorous bounds checking when copying or processing data into fixed-size buffers allocated on the heap. An attacker who can inject maliciously crafted IU-UP messages into the network traffic stream can exploit this miscalculation to write data beyond the allocated memory region. This overwriting corrupts adjacent memory structures, potentially including metadata used by the memory allocator such as size fields or pointers for subsequent allocations and deallocations. The immediate consequence of this corruption is typically a segmentation fault or application crash, resulting in an uncontrolled termination of the libosmocore process or any service relying on it.
The operational impact of this vulnerability is primarily focused on availability rather than confidentiality or integrity at first glance. As indicated by the initial description, the primary effect is a denial of service against the affected system. In a production telecommunications environment where libosmocore might be deployed in software-defined radio setups or small cell base stations, such a crash can disrupt local connectivity and signaling processes. While the immediate result is a crash, buffer overflows are historically significant because they provide an opportunity for arbitrary code execution if the attacker can precisely control the overwritten memory contents to redirect program flow. Although no remote code execution was explicitly confirmed in this specific report, the potential severity remains high due to the nature of heap corruption techniques that could allow privilege escalation or complete system compromise depending on the deployment context and operating system protections like ASLR and DEP.
This vulnerability aligns with MITRE ATT&CK technique T1498, specifically Network Denial of Service via resource exhaustion through application crashes. It also reflects common patterns seen in CWE-787, which involves out-of-bounds write vulnerabilities that lead to memory corruption. The lack of input validation is a classic example of insufficient trust boundaries for data received from network interfaces. In the context of mobile networks, where real-time signaling is critical, even brief interruptions caused by such crashes can degrade service quality or cause call drops in connected devices.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The most effective solution is to apply the official patch provided by the libosmocore maintainers that updates the library beyond version 1.14.1, ensuring that the osmo_iuup_compute_payload_crc function includes proper length checks before memory operations. Organizations relying on this software should verify their dependency versions and update accordingly through package managers or source compilation with the latest stable release. For environments where immediate patching is not feasible due to compatibility constraints, network-level filtering can be employed as a temporary countermeasure. This involves inspecting IU-UP traffic for anomalous payload sizes that exceed expected maximums defined by the 3GPP specifications and dropping packets that violate these limits before they reach the vulnerable application layer. Additionally, enabling runtime memory protection mechanisms such as Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) can mitigate the risk of exploitation leading to code execution, although it does not prevent the denial of service outcome. Regular security audits focusing on input validation in C/C++ applications are recommended to identify similar patterns across other components within the stack.