Skip to content

Conversation

@weebl2000
Copy link
Contributor

Severity: Low

Summary

Both ACK packet handlers in Mesh::onRecvPacket copy 4 bytes from the payload via memcpy before checking whether payload_len >= 4:

  1. Direct-route early ACK (line 83–86): memcpy then if (i <= pkt->payload_len)
  2. Flood ACK (line 118–121): memcpy then if (i > pkt->payload_len)

When payload_len < 4, the memcpy reads stale data from within the 184-byte payload buffer. The result (ack_crc) is discarded in both cases — the subsequent length check prevents it from being used — but the ordering is incorrect.

Fix

Move the payload_len >= 4 check before the memcpy in both locations. Short ACK packets are now rejected without touching the payload data.

Test plan

  • Normal ACK processing still works (direct and flood)
  • Short/corrupt ACK packets are silently dropped
  • Build tested on Heltec_v3_companion_radio_ble

Both ACK handlers (direct-route early ACK and flood ACK) copy 4 bytes
from the payload before checking payload_len >= 4. Move the bounds
check before the memcpy so short ACK packets are rejected without
reading stale buffer data.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant