As per Section 5.2.1 of the MQTT-SN specification, the MQTT-SN length
header is either 1- or 3-octet long. If it is 3-octet long then the
first octet is 0x01. The asymcute implementation currently only checks
that the incoming packet is at least 2-octet long before attempting to
parse it (MIN_PKT_LEN). However, if the first octet is 0x01 the packet
must be more than 3 octet long in order to be valid. Since asymcute
does not check this it reads one octet beyond the packet data for a
2-octet packet where the first octet has the value 0x01. This commit
fixes this issue by adding an additional sanity check to _len_get.
Currently, asymcute only matches an MQTT-SN request to its
acknowledgement using the MsgId header. However, I strongly believe
this to be insufficient as asymcute would thus also match a SUBACK
to a prior PUBLISH message (for example) as long as the message ID
matches. To address this issue, this commit modifies _req_preprocess
to also compare the request message type in addition to the message id.
The _parse_reply function iterates over the DHCPv6 message options
twice but only performs sanity checks on the option length in the
first iteration. As such, both loop iterations need to be identical.
Unfortunately, there aren't without this commit as (1) they use
different maximum length values and (2) the first iteration stops
parsing as soon as it encounters a zero option while the second
doesn't. As such, it is possible for out-of-bounds read to be
performed by the second loop iteration. This commit fixes this.
The handlers for these MQTT message lock the connection mutex on
function entry. During automated testing of asymcute, I discovered
return paths for these function which do not unlock the connection
mutex. This results in a deadlock which prevents asymcute from
sending any further messages.
The assertion is a bit overeager.
In case of receiving a wrong message ID, we re-try receive without
entering the STATE_REQUEST_SEND state again, so it is expected that
we get a non-NULL ctx/response from sock_udp_recv_buf().
What this assert should actually check is that we don't get a non-NULL
ctx after calling sock_udp_recv_buf() with a non-NULL ctx.
So make this explicit to not falsely fail the assertion.