Summary
parse_data_packet and parse_rref_response in crates/flight-xplane/src/udp_protocol.rs allocate vectors based on untrusted network input length. A malicious X-Plane plugin or network attacker could send packets with large payload.len() values, causing excessive memory allocation before the fixed-size loop processes each chunk.
Severity: Medium — DoS vector if OpenFlight's X-Plane plugin receives UDP from untrusted sources.
Affected Functions
parse_data_packet (line 76)
// TODO: Vec::with_capacity driven by untrusted input length — consider capping
// the allocation to a reasonable maximum (e.g., MAX_DATA_GROUPS) to prevent
// memory exhaustion from malformed packets.
let mut groups = Vec::with_capacity(payload.len() / DATA_GROUP_LEN);
parse_rref_response (line 150)
// TODO: Vec::with_capacity driven by untrusted input length — consider capping
// the allocation to a reasonable maximum to prevent memory exhaustion from
// malformed packets.
let mut entries = Vec::with_capacity(payload.len() / RREF_ENTRY_LEN);
Fix Plan
Add a constant for the maximum number of groups/entries, and cap the allocation:
const MAX_DATA_GROUPS: usize = 1_000; // example cap
const MAX_RREF_ENTRIES: usize = 1_000; // example cap
pub fn parse_data_packet(bytes: &[u8]) -> Result<XPlaneDataPacket, ParseError> {
// ...
let max_groups = (payload.len() / DATA_GROUP_LEN).min(MAX_DATA_GROUPS);
let mut groups = Vec::with_capacity(max_groups);
// ...
}
The choice of MAX_DATA_GROUPS / MAX_RREF_ENTRIES should be based on:
- What X-Plane actually sends (check specs/fixtures for maximum group counts)
- What the downstream consumers can actually handle
- Memory budget for a single packet parse
NOTE: The fuzz target fuzz_targets/fuzz_data_packet.rs already exercises this function with arbitrary bytes. Run cargo fuzz run fuzz_data_packet to see if the fuzzer finds a way to trigger excessive allocation.
Verification
cargo clippy --workspace -- -W clippy::pedantic 2>&1 | grep "Vec::with_capacity"
Labels
bug, security
Priority
Medium — concrete DoS vector, but only exploitable if OpenFlight's UDP listener receives untrusted input.
Summary
parse_data_packetandparse_rref_responseincrates/flight-xplane/src/udp_protocol.rsallocate vectors based on untrusted network input length. A malicious X-Plane plugin or network attacker could send packets with largepayload.len()values, causing excessive memory allocation before the fixed-size loop processes each chunk.Severity: Medium — DoS vector if OpenFlight's X-Plane plugin receives UDP from untrusted sources.
Affected Functions
parse_data_packet(line 76)parse_rref_response(line 150)Fix Plan
Add a constant for the maximum number of groups/entries, and cap the allocation:
The choice of
MAX_DATA_GROUPS/MAX_RREF_ENTRIESshould be based on:Verification
Labels
bug,securityPriority
Medium — concrete DoS vector, but only exploitable if OpenFlight's UDP listener receives untrusted input.