Fix out-of-bounds read in PATH payload parsing

[weebl2000]

Severity: Critical

Summary

When a node receives a PATH packet from a known contact, it decrypts the payload and parses a path_len field to find the route data inside. The problem is that path_len comes from the decrypted data itself, and nothing checks whether it's actually valid before using it to walk through the buffer.

A compromised or malicious contact can send a PATH packet where path_len claims to be much larger than the actual payload. The parser blindly advances past the end of the decrypted buffer and reads whatever happens to be in memory after it — stack variables, other packet data, etc. Depending on what onPeerPathRecv does with the resulting garbage pointers, this could crash the node or leak memory contents back to the attacker in a response.

Who can exploit this: any peer in your contacts list (they need a shared key for the MAC/decryption to pass).

What it takes: a single crafted PATH packet over RF.

What users might see

Even without a deliberate attack, this can be triggered by corrupted packets that happen to decrypt successfully (unlikely but possible with the 2-byte MAC). In practice, affected nodes could experience:

• Unexpected reboots or freezes — reading past the buffer can hit unmapped memory or corrupt the stack, causing a hard fault on ESP32/nRF52
• Broken path discovery — the node processes a garbage path and tries to route through it, leading to messages that never arrive or peers that appear unreachable
• Ghost routes — onPeerPathRecv stores a nonsense path for a contact, so subsequent direct messages to that peer get sent into the void until the next successful path exchange overwrites it
• Intermittent connectivity — if the node crashes and reboots, it loses all in-memory routing state and has to rediscover peers from scratch, causing periodic drops

Most of these would look like "flaky mesh" rather than a security issue, which is part of what makes it worth fixing.

Fix

One bounds check after reading path_len — verify the buffer actually has room for the claimed path plus the extra_type byte before touching any of it. If not, drop the packet silently, same as a failed decryption.

Test plan

• Normal PATH packet exchange still works (discovery, direct path return)
• No regressions in flood/direct routing
• Build tested on Heltec_v3_companion_radio_ble