nr-uesoftmodem crashes with SIGSEGV when receiving modified TimeDomainAllocationList (mappingType typeA↔️typeB)

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 TimeDomainAllocationList parameter mappingType. When the UE receives and processes this modified message, it triggers a segmentation fault and crashes immediately.

This mappingType appears in two different place in the RRCSetup Message, by modifying either one from current value typeA to typeB or from current value typeB to typeA in the falsified RRC message, and send this falsified RRC message to nr-uesoftmodem would cause segmentation fault.

First one is in the pdsch config at the path of message[1][1].criticalExtensions[1].masterCellGroup[1].spCellConfig.spCellConfigDedicated.downlinkBWP-ToAddModList[0].bwp-Common.pdsch-ConfigCommon[1].pdsch-TimeDomainAllocationList[0].mappingType in the RRC message

mac_101_message_screenshot

The GDB Debugging Output:

Thread 20 "UEthread_0" received signal SIGSEGV, Segmentation fault.
0x000061ab3dfa3504 in nr_ue_process_dci_dl_11(...)
    at /home/openairinterface5g/openair2/LAYER2/NR_MAC_UE/nr_ue_procedures.c:1077

1077: pdsch_Config->dmrs_DownlinkForPDSCH_MappingTypeB->choice.setup;

Second one is in the pusch config at the path of message[1][1].criticalExtensions[1].masterCellGroup[1].spCellConfig.spCellConfigDedicated.uplinkConfig.uplinkBWP-ToAddModList[0].bwp-Common.pusch-ConfigCommon[1].pusch-TimeDomainAllocationList[0].mappingType in the RRC message

mac_364_message_screenshot

The GDB Debugging Output:

Thread 20 "UEthread_0" received signal SIGSEGV, Segmentation fault.
0x00005a0f47f3d711 in nr_config_pusch_pdu(...)
    at /home/openairinterface5g/openair2/LAYER2/NR_MAC_UE/nr_ue_scheduler.c:840

840: NR_DMRS_ulconfig = (mappingtype == NR_PUSCH_TimeDomainResourceAllocation__mappingType_typeA)

Reproduction Environment

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

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

Potential Null Pointer Analysis

The vulnerability exists in the nr_ue_process_dci_dl_11 function where the code attempts to access DMRS configuration based on the mapping type received in the DCI message. The problematic code at line 1077 assumes that both dmrs_DownlinkForPDSCH_MappingTypeA and dmrs_DownlinkForPDSCH_MappingTypeB configurations are present and valid, selecting between them based on tda_info.mapping_type. However, in typical UE configurations, only TypeA mapping is configured while TypeB remains NULL. An attacker can exploit this by tampering with the DCI message transmitted over the air interface, specifically manipulating the time domain resource assignment field that determines the mapping type. When the tampered DCI indicates TypeB mapping, the code attempts to dereference pdsch_Config->dmrs_DownlinkForPDSCH_MappingTypeB->choice.setup without checking if it exists, resulting in a null pointer dereference that crashes the UE. This creates a remote denial-of-service vulnerability where an attacker with the ability to transmit malformed DCI messages can repeatedly crash victim UEs by simply toggling the mapping type field between TypeA and TypeB values.