Bounds-check reply_path in anonymous request handlers

[weebl2000]

Severity: Medium

Summary

The handleAnonRegionsReq, handleAnonOwnerReq, and handleAnonClockReq functions in the repeater firmware read a reply_path_len byte (masked to 0–63) from the decrypted payload and immediately memcpy that many bytes into reply_path. The caller passes a bare pointer (&data[5]) without any remaining-length information, so the handlers have no way to validate whether the data buffer actually contains reply_path_len bytes.

With a minimal-length anonymous request (16 bytes decrypted from one AES block), only 11 bytes remain after offset 5. A reply_path_len of 63 causes a read of 52 bytes of uninitialized stack memory into reply_path, which is then used to route the response.

Who can exploit this: any node — anonymous requests use ECDH with the receiver's public key, so any sender can produce a valid MAC.

What it takes: a single crafted ANON_REQ packet.

What users might see

The node sends a response with a garbage routing path, wasting airtime. The response is unlikely to be delivered. No crash — reads stay within the 184-byte data[] stack buffer.

Fix

• Add a data_len parameter to all three handleAnon*Req functions
• Validate 1 + reply_path_len <= data_len before the memcpy
• Guard the callers in onAnonDataRecv to ensure len > 5 before passing &data[5]

Test plan

• Anonymous discovery (regions, owner info, clock) still works
• Short/malformed anonymous requests are silently rejected
• Build tested on Heltec_v3_repeater