Validate buffer length before reading fields in Packet::readFrom

[weebl2000]

Severity: Low

Summary

Packet::readFrom reads the header byte, transport codes (4 bytes if present), and path_len from the source buffer before performing any length validation. With a short input (e.g. len = 0), these reads go past the end of the source buffer.

Unlike the main radio receive path (which parses packets inline in Dispatcher::checkRecv with proper bounds checking), readFrom is used by bridge interfaces (RS232, ESP-NOW) and importContact (flash blob storage). A corrupted blob or malformed bridge frame could trigger the over-read.

Fix

Add upfront length checks:

• Minimum 2 bytes overall (header + path_len)
• Transport codes require 4 additional bytes
• Path bytes plus at least 1 byte of payload must fit before proceeding

Test plan

• Bridge packet reception still works (RS232, ESP-NOW)
• Contact import/export still works
• Short/corrupt inputs return false without reading past the buffer
• Build tested on Heltec_v3_companion_radio_ble

---

Build firmware: Build from this branch

[446564]

I'll start testing

[446564]

at least nothing is broken in practical testing.

have you considered adding a few unit tests?

[liamcottle]

have you considered adding a few unit tests?

Once #925 is merged, it will make things like this easier to validate.

For example, create a new test with inputs that produce invalid/unexpected output, then fix the methods to ensure it behaves as expected.

Scott is reviewing #925 and which test framework is best to go with.

[mtlynch]

I'm working on similar fixes in https://github.com/mtlynch/mesh-core/pull/3/changes