Submit #891890: Open5gs AMF v2.7.7 Denial of Service

Open5GS Release, Revision, or Tag
v2.7.7

Description
AMF aborts when a normal old-GUTI registration causes the target AMF to
discover the previous AMF over namf-comm, send:

POST /namf-comm/v1/ue-contexts/{ueContextId}/transfer
and parse a forged old-AMF response whose
ueContext.mmContextList[*].allowedNssai contains more than
OGS_MAX_NUM_OF_SLICE entries.

This is a client-response trust boundary, not the already documented direct
server-side empty-body /transfer crash in report/amf/. The target AMF
accepts the old-AMF response, enters
amf_namf_comm_handle_ue_context_transfer_response(), and then
amf_namf_comm_decode_ue_mm_context_list() appends each allowedNssai entry
into a fixed-size internal slice array guarded only by:

ogs_assert(num_of_s_nssai < OGS_MAX_NUM_OF_SLICE);
at ../src/amf/namf-handler.c:1684.

This is also distinct from the companion nssaiMappingList variant on the same
route because that one hits a different assertion at
../src/amf/namf-handler.c:1699.

Root Cause
Entry chain:
old-GUTI registration to the target AMF
-> target AMF discovers old AMF over namf-comm
-> target AMF sends POST /namf-comm/v1/ue-contexts/{ueContextId}/transfer
-> amf_namf_comm_handle_ue_context_transfer_response()
-> amf_namf_comm_decode_ue_mm_context_list()
Crash site:
../src/amf/namf-handler.c:1684
Root cause family:
assertion on fixed-size array growth with attacker-controlled list length
Controlling field:
UeContextTransferRspData.ueContext.mmContextList[*].allowedNssai
Steps to Reproduce
Build the local Open5GS daemons and transfer harness:
ninja -C /home/ubuntu/open5gs_277/open5gs/build-audit \
src/nrf/open5gs-nrfd src/amf/open5gs-amfd src/ausf/open5gs-ausfd \
src/udm/open5gs-udmd src/udr/open5gs-udrd src/pcf/open5gs-pcfd \
tests/common/libtestcomon.a tests/transfer/transfer-fuzz
Use the local two-AMF transfer harness and fake old-AMF helper already
prepared in:
/home/ubuntu/open5gs_277/open5gs/tests/transfer/ue-context-transfer-fuzz-test.c
/home/ubuntu/open5gs_277/.audit_tmp/fake_old_amf_transfer.js
/home/ubuntu/open5gs_277/.audit_tmp/transfer-fuzz.yaml
Control experiment:
rm -f /home/ubuntu/open5gs_277/.audit_tmp/fake_old_amf_transfer.log \
/home/ubuntu/open5gs_277/.audit_tmp/transfer-control.log
timeout -k 2 25s \
env TRANSFER_FUZZ_MODE=control \
TRANSFER_FUZZ_CONFIG=/home/ubuntu/open5gs_277/.audit_tmp/transfer-fuzz.yaml \
/home/ubuntu/open5gs_277/open5gs/build-audit/tests/transfer/transfer-fuzz \
-c /home/ubuntu/open5gs_277/.audit_tmp/transfer-fuzz.yaml \
> /home/ubuntu/open5gs_277/.audit_tmp/transfer-control.log 2>&1
In my live run, this control case exited 0 and the fake old-AMF log showed a
normal /transfer request with no AMF crash.

Malicious experiment:
rm -f /home/ubuntu/open5gs_277/.audit_tmp/fake_old_amf_transfer.log \
/home/ubuntu/open5gs_277/.audit_tmp/transfer-allowed.log
timeout -k 2 25s \
env TRANSFER_FUZZ_MODE=allowed_nssai_overflow \
TRANSFER_FUZZ_CONFIG=/home/ubuntu/open5gs_277/.audit_tmp/transfer-fuzz.yaml \
/home/ubuntu/open5gs_277/open5gs/build-audit/tests/transfer/transfer-fuzz \
-c /home/ubuntu/open5gs_277/.audit_tmp/transfer-fuzz.yaml \
> /home/ubuntu/open5gs_277/.audit_tmp/transfer-allowed.log 2>&1
Inspect the fake old-AMF log and AMF crash log:
cat /home/ubuntu/open5gs_277/.audit_tmp/fake_old_amf_transfer.log
tail -n 120 /home/ubuntu/open5gs_277/.audit_tmp/transfer-allowed.log
Logs
Control evidence:

control harness exit code: 0
2026-04-11T14:42:48.911Z listening on 127.0.0.5:7777 mode=control supi=imsi-999700000000010
2026-04-11T14:42:49.079Z POST /namf-comm/v1/ue-contexts/5g-guti-9997002005fc00006e9/transfer mode=control body={"reason":"INIT_REG","accessType":"3GPP_ACCESS"}
04/11 22:42:49.075: [amf] INFO: [b2c11e2c-35b4-41f1-b05c-e3fd923f8114] Setup NF Instance [type:AMF] (../src/amf/nnrf-handler.c:168)
Malicious evidence:

malicious harness wrapper exit code: 134
2026-04-11T14:42:19.731Z listening on 127.0.0.5:7777 mode=allowed_nssai_overflow supi=imsi-999700000000010
2026-04-11T14:42:19.899Z POST /namf-comm/v1/ue-contexts/5g-guti-9997002005fc0000762/transfer mode=allowed_nssai_overflow body={"reason":"INIT_REG","accessType":"3GPP_ACCESS"}
04/11 22:42:19.895: [amf] INFO: [a15d0290-35b4-41f1-a54e-a369fbf6b413] Setup NF Instance [type:AMF] (../src/amf/nnrf-handler.c:168)
04/11 22:42:19.901: [amf] FATAL: amf_namf_comm_decode_ue_mm_context_list: Assertion `num_of_s_nssai < OGS_MAX_NUM_OF_SLICE' failed. (../src/amf/namf-handler.c:1684)
The wrapper exits 134 because the transfer harness hits a follow-on SCTP
fatal after the target AMF has already aborted.

Expected behaviour
The target AMF should reject malformed old-AMF /transfer response payloads
without asserting on allowedNssai length.

Observed Behaviour
A single malicious old-AMF /transfer response aborts the target AMF during
UE-context transfer handling.

eNodeB/gNodeB
UERANSIM gNB v3.2.7

UE Models and versions
UERANSIM UE v3.2.7

• Source: ⚠️ https://github.com/open5gs/open5gs/issues/4398
• User: ZiyuLin (UID 93568)
• Submission: 07/15/2026 15:31 (2 months ago)
• Moderation: 08/30/2026 08:10 (2 months later)
• Status: Accepted
• VulDB entry: 397082 [Open5GS up to 2.7.7 AMF src/amf/namf-handler.c amf_namf_comm_decode_ue_mm_context_list ueContext.mmContextList[*].allowedNssai memory corruption]
• Points: 20