Submit #844824: Open5GS 2.7.7 Denial of Serviceinfo

TitelOpen5GS 2.7.7 Denial of Service
BeschreibungOpen5GS v2.7.7 AMF contains a denial-of-service vulnerability in the NRF Discovery response handling path. The vulnerable code path is amf_nnrf_handle_nf_discover() in src/amf/nnrf-handler.c. This callback processes asynchronous NRF Discovery responses. During that processing, the AMF resolves a previously captured ran_ue_id using ran_ue_find_by_id() and then immediately asserts the returned RAN-UE context with ogs_assert(ran_ue), without first checking whether the context still exists. The affected logic is equivalent to: ran_ue = ran_ue_find_by_id(ran_ue_id); ogs_assert(ran_ue); This is unsafe because the NRF Discovery response may arrive after the associated RAN-UE context has already been removed. If the context no longer exists, ran_ue_find_by_id(ran_ue_id) returns NULL. The subsequent ogs_assert(ran_ue) fails and terminates the AMF process via ogs_abort(). The issue is a stale-context race in an AMF/SBI callback path. It can occur when an NRF Discovery transaction remains in flight while the related RAN-UE context is removed due to gNB-side disconnect, gNB N2/SCTP termination, SCTP shutdown or abort, gNB restart, NG Reset, UE context release, or similar cleanup. In the reported reproduction, the crash occurred when the following conditions coincided: 1. The SMF was absent from the AMF NF instance cache. 2. The AMF created an AMF session and triggered NSSF-assisted discovery. 3. The AMF sent an asynchronous NRF Discovery request. 4. The NRF Discovery response was delayed. 5. During the discovery window, the lab gNB N2/SCTP connection was terminated. 6. The AMF handled the N2 termination and removed the associated RAN-UE context. 7. The delayed NRF Discovery response later reached amf_nnrf_handle_nf_discover(). 8. ran_ue_find_by_id(ran_ue_id) returned NULL. 9. ogs_assert(ran_ue) failed and the AMF process aborted. Representative reproduction timeline: 15:43:12.560 NF_DEREGISTERED [type:SMF] - SMF removed from NF cache 15:43:22.205 Number of AMF-Sessions is now 1 - PDU Session created 15:43:22.206 No V-SMF Instance - NSSF fallback triggered 15:43:22.206 Try to discover [nnssf-nsselection] - NRF Discovery sent 15:43:22.986 SIGTERM sent to lab nr-gnb - SCTP graceful shutdown - ran_ue freed 15:43:28.651 FATAL: Assertion `ran_ue' failed. (nnrf-handler.c:89) Observed crash log: 05/03 15:43:28.651: [amf] FATAL: amf_nnrf_handle_nf_discover: Assertion `ran_ue' failed. (../src/amf/nnrf-handler.c:89) 05/03 15:43:28.652: [core] FATAL: backtrace() returned 8 addresses (../lib/core/ogs-abort.c:37) The crash was reproduced under controlled lab conditions. The Scapy SCTP ABORT method reproduced the AMF crash in 5 out of 5 trials. An additional validation using graceful SCTP shutdown via lab gNB SIGTERM reproduced the same AMF crash condition. The observed behavior is that the AMF process terminates immediately when the delayed NRF Discovery response is processed after the associated RAN-UE context has already been removed. The stored ran_ue_id no longer resolves to a valid RAN-UE context, ran_ue_find_by_id(ran_ue_id) returns NULL, ogs_assert(ran_ue) fails, and the AMF process terminates through ogs_abort(). As a result, active UE sessions are dropped until the AMF process is restarted. The direct security impact is availability loss. A successful trigger causes the AMF process to abort and interrupts service for active UE sessions until AMF restart. No confidentiality or integrity impact is claimed. The expected behavior is that the AMF should treat a missing RAN-UE context as a recoverable stale-context condition. Instead of asserting and terminating the process at NRF discovery-response time, the callback should check whether ran_ue_find_by_id() returned NULL. If the associated NG context has already been removed, the AMF should log the stale context condition, clean up or remove the related SBI transaction as appropriate, and return without aborting the AMF process. Vendor confirmation and fix status: The issue was reported to the Open5GS project as GitHub issue #4517. The maintainer classified the issue as Type:Security and added a fix commit referencing the report. The first fix commit is 1039401, “amf: handle stale RAN-UE in NRF discovery response”. The commit message states that the AMF should not assume that the RAN-UE captured when a session-scoped NRF discovery request was created is still alive when the discovery response arrives. It also states that a gNB-side disconnect or UE context release can remove the NG context while NRF discovery is still in flight. In that case, ran_ue_find_by_id() may return NULL, so the code should not assert on it at discovery-response time. Instead, ran_ue should be resolved only when it is actually needed to send a NAS/NGAP failure response in the no-NF-found path, and that response should be skipped if the NG context has already gone away. The same fix also makes SBI transaction ownership explicit for failed discovery paths. If no SearchResult is present, or if no matching NF instance is found, the transaction is no longer forwarded through amf_sbi_send_request(), so the xact is removed before returning. A follow-up refactor was merged through PR #4592, “amf: refactor NRF discovery failure handling”, as commit c427a53. The merged change moves NRF discovery failure handling into amf_nnrf_handle_failed_amf_discovery() so that both SBI client timeout and NRF discovery failure paths use the same cleanup and recovery logic. It removes duplicated failure handling from amf-sm.c and centralizes UE-scoped and session-scoped handling in nnrf-handler.c. For session-scoped failures, the refactor resolves the captured RAN-UE only at the point where a NAS/NGAP failure response must be sent, and handles stale, detached, or mismatched NG contexts without asserting. It also makes SBI transaction ownership explicit by removing the xact in the common failed-discovery handler before returning. The Open5GS project stated that it does not assign or request CVE IDs and that there is currently no CVE ID associated with this issue from the Open5GS side. Related Open5GS fixes: * 1039401, amf: handle stale RAN-UE in NRF discovery response * c427a53, amf: refactor NRF discovery failure handling * PR #4592, amf: refactor NRF discovery failure handling, merged into main References: * Open5GS GitHub Issue #4517 * Open5GS commit 1039401 * Open5GS commit c427a53 * Open5GS PR #4592
Quelle⚠️ https://github.com/open5gs/open5gs/issues/4517
Benutzer
 insengen (UID 98673)
Einreichung01.06.2026 13:17 (vor 1 Monat)
Moderieren03.07.2026 18:36 (1 month later)
StatusAkzeptiert
VulDB Eintrag376135 [Open5GS bis 2.7.7 AMF src/amf/nnrf-handler.c amf_nnrf_handle_nf_discover Denial of Service]
Punkte20

Want to stay up to date on a daily basis?

Enable the mail alert feature now!