SRXL2: Integer underflow in srxlParsePacket()leads to ~4GB memcpy overflow

I have discovered a high-severity buffer overflow vulnerability in the ArduPilot SRXL2 protocol parsing function srxlParsePacket(). Due to a lack of validation on the minimum value of the attacker-controlled pRx->header.lengthfield, supplying a value less than 10 triggers an unsigned integer underflow. This causes memcpyto attempt writing approximately 4GB of data into a global buffer of only 64 bytes, resulting in memory corruption and potentially leading to remote code execution (RCE). I have provided a fix that includes boundary checks to address this issue.

I am not sure if my analysis is entirely correct, so I welcome everyone to review and discuss it together.

SRXL2_srxlParsePacket_integer_underflow.pdf (104.4 KB)

That isn’t high serverity IMHO, the surface of attack is quite difficult and we won’t will just underflow the uint8_t, and there is now RCE on our devices …

I didn’t test , but pretty sure ardupilot/libraries/AP_RCProtocol/spm_srxl.cpp at 1b7d3cde13fa11161c8879b14ca725dea9d84a1d · ArduPilot/ardupilot · GitHub is a guard already against this potential issue.

If you want to unsure, use gdb and send a corrupted packet to see what happens.

Thank you for the quick response.I will run further tests to verify this.