mirror of
https://github.com/meshcore-dev/MeshCore.git
synced 2026-10-24 08:22:37 +00:00
Marcel Verdult
56b5f4e9c6
CMD_SEND_CHANNEL_TXT_MSG reads txt_type, channel_idx and a 4 byte timestamp, so
the frame needs 7 bytes before the text starts, and the branch had no length
guard. For a shorter frame "len - i" is computed in size_t, wraps, and reaches
sendGroupMessage() as a negative int. The clamp there tests
"text_len + prefix_len > MAX_TEXT_LEN", which a negative value passes, and the
following memcpy() converts the length back to a size_t: a 3 byte frame asks for
4294967292 bytes into a 197 byte stack buffer.
Two guards, because there are two mistakes. The branch now states its minimum
like most other branches of handleCmdFrame do, so a frame below 7 bytes is
answered through the existing path instead of being parsed. And
sendGroupMessage() refuses a negative length the way sendGroupData() in the same
file already does, which protects every other caller.
A frame of exactly 7 bytes keeps working and sends an empty message, as before.
Evidence. On a T-Echo running dev 428a95c6, built with
FIRMWARE_BUILD_DATE "f1-dev" and confirmed by "ver => v1.18.0 (Build: f1-dev)":
CH_TXT len=7 -> RESP_CODE_OK
GET_STATS core -> uptime=78s
CH_TXT len=3 -> NO REPLY
DEVICE_QUERY -> NO REPLY (three times over 8 s, node never came back)