Validate decrypted PATH path_len against MAX_PATH_SIZE

[weebl2000]

Severity: Critical

Summary

The path_len field inside decrypted PATH payloads is validated against the decrypted buffer size (by #1654) but not against MAX_PATH_SIZE (64). A malicious contact can send a PATH packet where the inner path_len is up to 178, which passes the buffer bounds check but then overflows two 64-byte arrays:

1. client->out_path[64] — in all onPeerPathRecv implementations (repeater, room server, sensor, BaseChatMesh), the path is copied via memcpy(client->out_path, path, client->out_path_len = path_len). With path_len > 64, this overwrites adjacent struct members (shared_secret, permissions, timestamps).

2. packet->path[64] — in sendDirect, the non-TRACE branch does memcpy(packet->path, path, packet->path_len = path_len) without checking against MAX_PATH_SIZE.

The TRACE branch of sendDirect also appends path data to the payload without checking payload_len + path_len <= MAX_PACKET_PAYLOAD.

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

A malicious contact could crash/reboot your node, corrupt routing state for other contacts, or potentially escalate privileges by overwriting the permissions field of adjacent ACL entries.

Fix

• Add path_len > MAX_PATH_SIZE check after parsing path_len from the decrypted PATH payload, before any use
• Add defensive bounds checks in sendDirect for both the TRACE payload-append path and the normal path-copy path, freeing the packet on overflow

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

---

Build firmware: Build from this branch