ofh: gNB process exit when U-plane get a not support compression type
Description
The dynamic U-plane decoder crash (process exit) when it get a section that use a compression type we not support. One bad uplink packet from the fronthaul can stop the whole gNB process.
Setup Details
- OCUDU
devbranch (I test on commitb81cbcec2f). - No special hardware need. This is in the U-plane decode path, so a crafted packet is enough to hit it.
- I find this by fuzz the U-plane decoder together with the real decompressor selector,
the same one
ofh_receiver_factories.cppbuild for production.
Actual Behavior
uplane_message_decoder_dynamic_compression_impl read the compression type from each
section udCompHdr. It only reject reserved (value 7). For value 2 to 6 (block scaling,
mu-law, modulation, bfp selective, mod selective) the selector return
iq_compression_death_impl. Its decompress() call report_error(), and report_error()
do quick_exit(). So the process just exit. The log before it exit:
OCUDU ERROR: Decompression type 'Mu law' is not supportedExpected Behavior
Decoder should drop this packet and keep run, same like it already do for reserved type.
One packet from the RU must not kill the gNB.
Steps to Reproduce
- Run the gNB with OFH split 7.2 so the dynamic U-plane decoder is use.
- Send one uplink U-plane packet, set the section
udCompHdrlow 4 bit to a not-support type, for example0x2(block scaling). - The decode reach
iq_compression_death_impl::decompressand the process exit.
For unit level you can also call uplane_message_decoder_dynamic_compression_impl::decode()
with such packet and the real selector from create_iq_decompressor_selector.
Possible Solution (Optional)
I already have a fix and a unit test. The idea is add is_supported() to iq_decompressor,
death impl return false, selector ask the decompressor of that type. Then the decoder drop
the message when is_supported() is false, same way like reserved. Only the dynamic
decoder need it, static decoder get the type from config not from wire. I can send a MR.
Additional Context
Maybe relate to #354 (metric for dropped/corrupt packet), because this is also a packet that should be drop but now it crash instead.