nr-uesoftmodem crashes with SIGSEGV when receiving modified SRS configuration (nrofSymbols n1→n4)

Overview When conducting testing with nr-uesoftmodem(2025.w05), find a potential security issue that causes UE crashes when processing modified RRC messages.

Issue Details During the testing, I intercepted and modified the RRCSetup message, specifically changing the SRS configuration parameter nrofSymbols from n1 to n4. When the UE receives and processes this modified message, it triggers a segmentation fault and crashes immediately.

Falsified RRC message and the falsified field nrofSymbols

message_screenshot

Modified Parameter Path in RRC message:

RRCSetup → masterCellGroup → spCellConfig → spCellConfigDedicated → 
uplinkConfig → uplinkBWP-ToAddModList[0] → bwp-Dedicated → 
srs-Config → srs-ResourceToAddModList[0] → resourceMapping → nrofSymbols

GDB Debugging Output:

Thread 19 "UL__actor" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x71d0cdffb640 (LWP 13201)]
0x00005774ff191cb5 in generate_srs_nr (srs_config_pdu=<optimized out>, 
    frame_parms=<optimized out>, txdataF=<optimized out>, 
    symbol_offset=<optimized out>, nr_srs_info=<optimized out>, 
    amp=<optimized out>, frame_number=<optimized out>, 
    slot_number=<optimized out>) 
    at /home/openairinterface5g/openair1/PHY/NR_UE_TRANSPORT/srs_modulation_nr.c:383
383             c16_t r_amp = {(((int32_t)round((double)amp * r.r / sqrt_N_ap)) >> 15),

Reproduction Environment I can continue to provide the followings if there is a need:

  • Docker environment for easy reproduction
  • GDB commands used for debugging

Preliminary Code Analysis After reviewing the latest version of srs_modulation_nr.c, I noticed that the crash occurs in the SRS generation loop. The code appears to lack boundary checks when N_symb_SRS increases from 1 to 4, potentially causing buffer overflow when accessing txdataF array.

Specifically:

  • Increasing nrofSymbols to 4 would require symbols 13, 14, 15, 16
  • When SRS symbols are configured near the end of a slot (e.g., starting at symbol 13)
  • But a slot only contains symbols 0-13
  • This leads to out-of-bounds memory access

The vulnerable code section:

for (int l_line = 0; l_line < nr_srs_info->N_symb_SRS; l_line++) {
    uint16_t l_line_offset = l_line * frame_parms->ofdm_symbol_size;
    // ...
    txdataF[p_index][symbol_offset + l_line_offset + subcarrier] = r_amp;
    // No bounds checking before this memory access
}
Edited by Jaroslava Fiedlerova