Fix out-of-bounds read in TRACE packet hash matching

[weebl2000]

Severity: Medium

Summary

The TRACE packet handler compares this node's identity hash against an entry in the payload to decide whether to forward the packet. The hash size is variable — 1, 2, 4, or 8 bytes depending on the path_sz field in the packet flags. The existing bounds check (offset >= len) only verifies that the start of the hash is within the payload, but doesn't account for the full hash length. When offset is close to the end of the payload, isHashMatch reads past the valid payload bytes.

Impact

The over-read stays within the payload[184] array in the Packet struct — it reads stale data from previous packets in the pool, not unmapped memory. This means it won't crash or hard-fault any node.

The practical effect is incorrect routing decisions for TRACE packets:

• False negative (most likely): stale bytes don't match the node's pub_key prefix → packet silently dropped when it should have been forwarded → broken/unreliable path traces.
• False positive (unlikely): stale bytes happen to match → packet forwarded when it shouldn't be.

Any node on the mesh can trigger this since TRACE packets are unauthenticated and direct-routed. A crafted packet with path_sz = 3 (8-byte hashes) and a payload length that leaves fewer than 8 bytes after the offset will hit this path.

Fix

Add a bounds check ensuring offset + hash_sz <= len before calling isHashMatch. Packets that don't have enough payload bytes for a full hash comparison are now silently dropped.

Test plan

• Normal path traces still work (single-byte and multi-byte hash modes)
• TRACE packets that reach end of path still handled correctly (offset >= len branch)
• Build tested on Heltec_v3_companion_radio_ble

---

Build firmware: Build from this branch