Minamikotor1

A remote unauthenticated attacker can cause the near-RT RIC to crash on port 36421. The issue occurs when an SCTP (Stream Control Transmission Protocol) association is closed before an `E2 SETUP REQUEST` is sent. The system incorrectly assumes a mapping between the SCTP association and the E2 node always exists during the cleanup path and enforces this using an `assert()` function, leading to a crash if the mapping is missing. This can be triggered by completing an SCTP handshake and disconnecting immediately without sending any E2AP messages.

The software crashes when it receives a RIC SUBSCRIPTION RESPONSE containing an unknown `ric id` that lacks a corresponding pending event. The near-RT RIC employs the `assert()` function to verify the existence of a pending event during response processing. A remote unauthenticated attacker can send a forged RIC SUBSCRIPTION RESPONSE to the near-RT RIC on port 36421, resulting in a SIGABRT (abnormal termination) in Debug builds or a NULL pointer dereference (SIGSEGV), which occurs when a program attempts to access a memory location that is not mapped, in Release builds.

The software uses hardcoded assertions to validate Information Element (IE) counts in decoded E2AP messages. A remote unauthenticated attacker can send a valid E2AP PDU containing an unexpected number of IEs, such as an `E2setupRequest` with extra optional fields, to crash the near-RT RIC (port 36421) or iApp (port 36422) via SIGABRT. This occurs because the code requires exact IE counts instead of validating them against the ranges specified by the protocol.

A reachable assertion exists in the `e2ap recv sctp msg()` function within `src/lib/ep/e2ap ep.c`. The function uses a fixed 32KB receive buffer and enforces an assertion on the return value of `sctp recvmsg()`. A remote unauthenticated attacker can cause a crash of the near-RT RIC, iApp, E2 Agent, or xApp process by sending a single SCTP message with a payload of 32,768 bytes or more, triggering a SIGABRT. This issue affects all four SCTP endpoint types on ports 36421 and 36422 and does not require a valid E2AP PDU. In Release builds (NDEBUG), the absence of the assertion can result in a signed-to-unsigned integer overflow and a potential out-of-bounds read.

The near-RT RIC crashes when it receives a RIC INDICATION message containing a `ran func id` that is not present in its registry. This occurs because the lookup process returns NULL, which leads to an assert() failure in Debug builds (SIGABRT) or a NULL pointer dereference in Release builds (SIGSEGV). A remote unauthenticated attacker can trigger this crash by sending a specially crafted RIC INDICATION message with an arbitrary `ran func id` value to port 36421.

An issue exists in the E2SM-KPM RAN Function's PRB utilization metric calculation within the `nr-softmodem` component. The functions `fill RRU PrbTotDl()` and `fill RRU PrbTotUl()` compute PRB usage percentages by dividing by the difference of two consecutive `total prb aggregate` samples without verifying if the divisor is zero. A malicious xApp can trigger this by sending a high volume of `E42 RIC SUBSCRIPTION REQUESTs` via the FlexRIC iApp on port 36422/SCTP, causing the E2 Agent to generate KPM Indication reports at a high frequency. If two consecutive sampling intervals produce identical PRB aggregate values, a division by zero occurs, triggering a SIGFPE (floating-point exception) and crashing the 5G base station process. This leads to a complete interruption of 5G cell service for all connected User Equipment (UE). No authentication is required to exploit this issue.

An authorization bypass exists in the iApp xApp isolation mechanism. The function `eq xapp ric gen id()` in src/ric/iApp/xapp ric id.c incorrectly compares `m0->xapp id` against itself instead of comparing it to `m1->xapp id`, which ignores the xApp identity dimension. Consequently, a malicious xApp connected to the iApp via port 36422 can delete subscriptions belonging to any other xApp by sending an E42 RIC SUBSCRIPTION DELETE REQUEST with a matching `ric gen id`. This flaw compromises multi-tenant isolation in deployments where multiple xApps share the same RIC.

A flaw allows a single SCTP connection to bind multiple `xapp ids` by sending multiple `E42 SETUP REQUESTs`. Upon disconnection, the system only cleans up resources for the first registered `xapp id`, leaving subsequent `xapp ids` and their subscriptions as stale entries. A remote attacker can exploit this to leak subscription state in the iApp, which may lead to state corruption or resource exhaustion over time.