NR UE Seg Fault integrityProtAlgorithm and sn-FieldLength
The issue is that an OPTIONAL field is accessed directly when handling the DL-DCCH message in the NR UE. The problem can be found in 2025.w45/openair2/RRC/NR_UE/rrc_UE.c, around line 655.
if (radioBearerConfig->securityConfig->securityAlgorithmConfig) {
ue_rrc->cipheringAlgorithm = radioBearerConfig->securityConfig->securityAlgorithmConfig->cipheringAlgorithm;
ue_rrc->integrityProtAlgorithm = *radioBearerConfig->securityConfig->securityAlgorithmConfig->integrityProtAlgorithm;
}
The ASN.1 definition is
SecurityAlgorithmConfig ::= SEQUENCE {
cipheringAlgorithm CipheringAlgorithm,
integrityProtAlgorithm IntegrityProtAlgorithm OPTIONAL, -- Need R
...
}
where integrityProtAlgorithm is an optional field. So a malformed message could set the field to missing and trigger a seg fault. An example DL-DCCH message can set the security config to something like
<securityConfig>
<securityAlgorithmConfig>
<cipheringAlgorithm>
<nea0/>
</cipheringAlgorithm>
</securityAlgorithmConfig>
</securityConfig>
Another similar issue is in openair2/LAYER2/nr_rlc/nr_rlc_oai_api.c, around line 697.
if (*am->dl_AM_RLC.sn_FieldLength != *am->ul_AM_RLC.sn_FieldLength) {
LOG_E(RLC, "%s:%d:%s: fatal\n", __FILE__, __LINE__, __FUNCTION__);
exit(1);
}
The sn-FieldLength field in both DL-AM-RLC and UL-AM-RLC messages are OPTIONAL. But here the code directly access those fields without checking their presence. This can cause seg fault from crafted DL-DCCH-Message.
DL-AM-RLC ::= SEQUENCE {
sn-FieldLength SN-FieldLengthAM OPTIONAL, -- Cond Reestab
t-Reassembly T-Reassembly,
t-StatusProhibit T-StatusProhibit
}
UL-AM-RLC ::= SEQUENCE {
sn-FieldLength SN-FieldLengthAM OPTIONAL, -- Cond Reestab
t-PollRetransmit T-PollRetransmit,
pollPDU PollPDU,
pollByte PollByte,
maxRetxThreshold ENUMERATED { t1, t2, t3, t4, t6, t8, t16, t32 }
}
Edited by XIAOTIAN ZHOU