Request for private security disclosure channel

[Fu1cr4m]

Hi maintainers, I am a security researcher conducting responsible security research on open-source flight controller firmware. I believe I have identified one or more security-relevant issues in this repository. I do not want to disclose technical details publicly in an issue before the maintainers have had a chance to review and coordinate a fix. Could you please provide a preferred private security contact channel, or enable GitHub Private Vulnerability Reporting for this repository? I can provide the following information privately: - affected version / commit range - vulnerability summary - affected component category - local reproduction environment - sanitizer / crash evidence where applicable - minimal proof-of-concept input or harness - impact assessment - suggested remediation direction I have not tested against real vehicles or third-party systems. My validation is limited to local code review, local builds, and controlled reproduction where applicable. Thank you for your work on this project. I would like to coordinate disclosure responsibly and avoid exposing actionable details publicly. Best regards, Fu1cr4m

[digitalentity]

Please share the nature of the vuln here - which component, what is the effect, what is the exploitation path. No need to provide the functional exploit.

[Fu1cr4m]

Please share the nature of the vuln here - which component, what is the effect, what is the exploitation path. No need to provide the functional exploit.
Thanks for the quick response. To clarify, I do not currently have a confirmed functional
exploit against iNAV.

The issue I wanted to report is a potential MSP input-validation / hardening concern in
the MSP SET command handling path, mainly in:

• src/main/fc/fc_msp.c
• the MSP input deserialization path using sbufReadU8/U16/U32 and sbufReadData
• related streambuf primitives where the unsafe read variants advance src->ptr without
  checking src->end

The general pattern is that attacker-controlled MSP payload bytes are consumed by
sbufRead* primitives inside MSP SET command handlers. If a handler does not strictly
validate the payload length before all reads, a short or malformed MSP frame can cause
under-payload reads past the declared payload buffer. In other MSP implementations with
similar streambuf primitives, this pattern can lead to OOB reads, configuration
pollution, or unsafe control-parameter updates.

For iNAV specifically, my current static analysis did not identify a confirmed HIGH-
severity instance. iNAV appears to be more defensive than related MSP implementations
because many handlers use either Safe read variants or explicit dataSize checks. However,
I found several medium-priority candidates where unsafe sbufRead* calls are still used
and correctness depends on manual dataSize guards rather than Safe APIs.

The candidates I would suggest auditing are:

• MSP_SET_RC_TUNING around fc_msp.c:2063
• MSP2_INAV_SET_RATE_PROFILE around fc_msp.c:2092
• MSP2_INAV_SET_AUX_RC around fc_msp.c:2427
• MSP_OSD_CHAR_WRITE around fc_msp.c:2930
• MSP2_COMMON_SET_MSP_RC_INFO around fc_msp.c:3225
• MSP_SET_RX_MAP around fc_msp.c:3282

For example, MSP_SET_RX_MAP has an equality guard on dataSize and appears safe after
manual review, so I would not claim that one as exploitable. The broader concern is that
these paths still rely on each handler getting the size checks exactly right while using
unsafe read primitives.

Potential effect, if any such guard is incomplete:

• under-payload OOB read from the MSP input buffer;
• unintended update of configuration/profile/control fields from bytes outside the
  declared payload;
• possible later exposure through corresponding MSP GET commands or persisted
  configuration paths, depending on the command.

Exploitation path at a high level:

1. An attacker with MSP access sends a malformed MSP SET frame with a shorter or
   inconsistent payload than the handler expects.
2. The handler enters the corresponding command case.
3. The case reads fields with unsafe sbufRead* primitives.
4. If the case-specific dataSize/sbufBytesRemaining validation is incomplete, reads may
   advance past the declared payload and bind unintended bytes into configuration or control
   structures.

I am not sharing a functional exploit, and at this point I would classify this for iNAV
as a defensive audit / hardening report rather than a confirmed vulnerability. The
remediation direction would be to either replace remaining unsafe sbufRead* uses in SET
handlers with Safe variants, or enforce exact dataSize / sbufBytesRemaining checks
immediately before all multi-field reads.

[sensei-hacker]

Thanks for getting in touch. In the future, you can reach me or other developers on the INAV Discord. https://discord.gg/peg2hhbYwN

I am a security professional and the current INAV maintainer.

I think you have found something that MAY warrant a PATCH. Let's first consider this from a security perspective, before looking at it in a different way.

I'm going to add one step to your "Exploitation path at a high level", and show a shorter version that starts out the same way.

1. Attacker connects a USB cable to the flight controller and to their laptop
2. Attacker sends a malformed MSP SET frame with a shorter or inconsistent payload than the handler expects.
3. The handler enters the corresponding command case.
4. The case reads fields with unsafe sbufRead* primitives.
5. If the case-specific dataSize/sbufBytesRemaining validation is incomplete, reads may advance past the declared payload and bind unintended bytes into configuration or control structures.

Shorter attack path:

1. Attacker connects a USB cable to the flight controller and to their 6S battery
2. The flight controller burns up

Or if you have an RF setup passing MSP commands wirelessly and have not secured that RF communication:

Long path:

1. Attacker hijacks the RF link carrying MSP
2. Attacker sends a malformed MSP SET frame with a shorter or inconsistent payload than the handler expects.
3. The handler enters the corresponding command case.
4. The case reads fields with unsafe sbufRead* primitives.
5. If the case-specific dataSize/sbufBytesRemaining validation is incomplete, reads may advance past the declared payload and bind unintended bytes into configuration or control structures.
6. Aircraft crashes

Short path:

1. Attacker hijacks the RF link carrying MSP
2. Attacker uses MSP to command motor disarm and put the aircraft into a 90 degree dive straight into the ground

If an attacker has control of the device, they can destroy the device. That's essentially always true, and so not a security concern. If you have physical control of any object, you can simply throw it on the ground to break it. (FIDO2 security keys and certain other items have unique security properties in this regard, but those properties don't apply here). The defense here is don't let an attacker have control of your device - put unattended devices in a locked building or room, use proper cryptographic authentication on wireless communication links.

HOWEVER, consider this alternative path:

1. Pilot using a wireless (or wired?) MSP link
2. Interference from the ESC or VTX corrupts a bit in the serial communication, resulting in a malformed MSP SET frame
3. The handler enters the corresponding command case.
4. The case reads fields with unsafe sbufRead* primitives.
5. If the case-specific dataSize/sbufBytesRemaining validation is incomplete, reads may advance past the declared payload and bind unintended bytes into configuration or control structures.

This may be worth looking at from a reliability standpoint. Patches would be welcomed. However, note that the length of an MSP message can change between versions, and it is acceptable for a sender to send a payload longer than the receiver parses - the receiver should disregard the extra optional bytes at the end.