emcute: never return from receive loop #12382
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Contribution description
The receive thread of the MQTT-SN implementation emcute returns from the packet receive loop if
sock_udp_recvreturns an error. This is, for instance, the case when a given packet doesn't fit into the supplied buffer. This condition can be triggered by anyone able to send large packets (> 512 byte) to the UDP socket. If so, this will stop the MQTT client from working until the device is restarted, i.e.emcute_runis invoked again.RIOT/sys/net/application_layer/emcute/emcute.c
Lines 515 to 521 in 89afc37
Testing procedure
My tap configuration is as follows:
sys/net/application_layer/emcute/emcute.c.examples/emcute_mqttsn.sock_udp_recvto return-ENOBUFS.Spoof the reply, e.g. using:
This should cause
emcute_runto return and output the message[emcute] error while receiving UDP packet. Afterwards, it should no longer be possible to connect to a working MQTT-SN server since emcute will nerver receive the CONNACK reply from it since it doesn't read from the socket anymore.Impact
Denial of service, a spoofed server message will cause the emcute client to stop working until
emcute_runis invoked again which is usually the case when the device is restarted.