Crafted MAVLink Packet leads to hard fault

[michaelprooney]

Bug report

Issue details

I was fuzzing the mavlink handler inside of GCS_MAVLINK::update_receive and was crafting packets like so:

    while (true) {
        read_count = fuzz_buffer_read(last_anchor_id, g_fuzzing_input, sizeof(g_fuzzing_input));
        if (read_count > 15 && read_count < 262) {
            break;
        }
        fuzz_finish(last_anchor_id);
    }
    // one byte length
    uint8_t length = g_fuzzing_input[0];
    // 24-bits to msgid
    uint32_t msgid =
        ((uint32_t)g_fuzzing_input[1] & 0xFF) << 16 |
        ((uint32_t)g_fuzzing_input[2] & 0xFF) << 8  |
        ((uint32_t)g_fuzzing_input[3] & 0xFF);
    // get crc extra from mavlink message entry
    const mavlink_msg_entry_t *mavlink_msg_entry = mavlink_get_msg_entry(msgid);
    if (mavlink_msg_entry == NULL) {
        // fprintf(stderr, "Unknown MAVLink message ID: %u\n", msgid);
        fuzz_finish(last_anchor_id);
        goto fuzz;
    }

    uint8_t crc_extra = mavlink_msg_entry->crc_extra;

    uint8_t sys_id = g_fuzzing_input[4];
    uint8_t comp_id = g_fuzzing_input[5];

    // payload is rest of data
    const uint8_t *payload = (const uint8_t *)&g_fuzzing_input[6];
    // real length is total - 6 bytes
    uint8_t real_length = read_count - 6;
    assign_fuzzed_input(msgid, crc_extra, payload, length, real_length, sys_id, comp_id);
    create_fuzzed_mavlink_packet(msgid, crc_extra, payload, length, real_length, sys_id, comp_id);
    restore_registers();

During this campaign I found one packet that caused a hard fault. My environment is an my own orchestrated version of QEMU capable of rehosting ArduPilot vehicles and I believe these bugs are worth checking out on real hardware. I select all for the platform because the GCS_MAVLINK class is a library. See the logs to find my exact input/payload. I have yet to fully triage this one but it deterministically hard faults in my orchestrated QEMU instance

Version
ArduRover release v4.6.2

Platform
[X] All
[ ] AntennaTracker
[ ] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Airframe type
Rover

Hardware type
QEMU instance rehosting firmware designed for CubeBlack flight controller.

Logs

Length: 32, MsgID: 75, CRC Extra: 158, Real Length: 32, SysID: 126, CompID: 42
72 00 B4 9B 7F 97 00 FF 01 00 7F 00 00 00 20 47 
B3 A2 6E 75 4C 82 00 91 91 91 10 00 91 01 00 65

[tpwrules]

Please supply more of the test harness so we can understand how the fuzzed data is being fed into the firmware. It should be a simple matter to compile with debug symbols and get a backtrace from QEMU as well. It would also be helpful to decode the payload so it is obvious what the field values are.

In general, ArduPilot is not designed to be robust to arbitrary MAVLink messages due to the resources required to validate every combination of payloads. It is also impossible to determine the safety of many payloads, as they depend on the particular vehicle and mission etc.

There are payloads for MsgID 75 in particular which deliberately cause an adverse effect as a debugging tool, so the fact that some other payloads also cause a problem is not very interesting.

The 16 bit CRC provides some protection against random data interpreted as, or corruption causing mutations into, a message with an adverse effect. For high-strength protection against corrupt or malicious messages, MAVLink signing needs to be used.

If your fuzzer can find a message with an incorrect CRC (or other malformation in the framing) that causes a problem, then this would be a serious issue. So would a message that causes a problem on a vehicle with signing enabled from a source that does not know the correct key (noting that the key is ignored over USB). But it doesn't seem clear from this description that your fuzzer is capable of finding issues like this.

[peterbarker]

While waiting for more information from @michaelprooney I thought I'd have a go at injecting that data (with Claude's help)

inject_issue_32121.py

pbarker@crun:~/rc/ardupilot((HEAD detached at Rover-4.6.2))$ ./Tools/autotest/sim_vehicle.py -v Rover --gdb --debug

pbarker@crun:~/rc/ardupilot-claude(master)$ ./inject_issue_32121.py tcp:localhost:5762
Decoded COMMAND_INT from wire payload:
  param1           = -2.977879e-22 (0x7200b49b)
  param2           = -1.709278e+38 (0x7f9700ff)
  param3           = 1.166311e-38 (0x01007f00)
  param4           = 4.096000e+04 (0x00002047)
  x                = 1970184883 (0xb3a26e75)
  y                = -1862237620 (0x4c820091)
  z                = 1.521587e-39 (0x91911000)
  command          = 401 (0x9101)
  target_system    = 0
  target_component = 101
  frame            = 0
  current          = 0
  autocontinue     = 0

Connecting to tcp:localhost:5762
Connected (system 1 component 0)
Packet sent
pbarker@crun:~/rc/ardupilot-claude(master)$ 

No crash....

The decoding looks right to me.