Broker, client, and MQTT v5 packet validation and reliability fixes#552
Broker, client, and MQTT v5 packet validation and reliability fixes#552aidangarske wants to merge 34 commits into
Conversation
… sub/unsub property cleanup
…shot sub iterator
…tize peer strings in broker log sinks
…gs in example log output
…erification, and log injection
…5 props, fix packet-size comparison
…ll re-entrancy, scoped wolfSSL cleanup, fan-out write reset
… PUBACK on topic alloc failure
…et credential staging buffer
…roker publish, enforce retained cap on persist restore
…cap at 1, count restore cap skips
…unsubscribe-reject test
… reap tombstones after delivery
embhorn
left a comment
There was a problem hiding this comment.
Couple minor things to clean up
…isconnect, and Auth decoders
embhorn
left a comment
There was a problem hiding this comment.
Skoll Code Review
Scan type: review
Overall recommendation: COMMENT
Findings: 5 total — 3 posted, 2 skipped
2 finding(s) posted as inline comments (see file-level comments below)
Posted findings
- [Medium] Per-client subscription cap default can be surprisingly small and silently rejects subscriptions —
src/mqtt_broker.c:2806-2812 (cap check); wolfmqtt/mqtt_broker.h:96-106 (default) - [Medium] MqttClient_Auth rx_buf scrub runs unlocked, racing concurrent reads in MULTITHREAD —
src/mqtt_client.c:2924 - [Low] Static fan-out: misleading comment and write attempted to a just-closed peer's other matching sub —
src/mqtt_broker.c:5312-5325
Skipped findings
- [Low]
New v5 DISCONNECT-with-Will (reason 0x04) broker path has no dedicated test - [Low]
MQTT_MAX_PROPS cap may reject spec-legal v5 messages with many User Properties
Review generated by Skoll
| * delivered auth->props to the property callback and then freed them and | ||
| * set auth->props = NULL. So the bytes are consumed before this scrub and | ||
| * the caller has no live pointer into rx_buf. */ | ||
| CLIENT_FORCE_ZERO(client->rx_buf, client->rx_buf_len); |
There was a problem hiding this comment.
🟠 [Medium] MqttClient_Auth rx_buf scrub runs unlocked, racing concurrent reads in MULTITHREAD
The new CLIENT_FORCE_ZERO(client->rx_buf, client->rx_buf_len) scrub is placed AFTER MqttClient_WaitType has returned and after lockClient was released (line ~2914), and it is not guarded by lockRecv. In a WOLFMQTT_MULTITHREAD build another thread can already be inside…
Fix: Wrap the rx_buf scrub in the receive lock in MULTITHREAD builds, mirroring the tx_buf scrub discipline.
| (void)MqttPacket_Write(&sub->client->client, | ||
| BrokerLog_Sanitize(topic), eff_qos, | ||
| (unsigned)pub.total_len); | ||
| wr = MqttPacket_Write(&sub->client->client, |
There was a problem hiding this comment.
🔵 [Low] Static fan-out: misleading comment and write attempted to a just-closed peer's other matching sub
Two minor issues in the new static-memory partial-write teardown: (1) The comment states "Removal is deferred so next_sub stays valid this iteration," but next_sub only exists in the dynamic (#ifndef WOLFMQTT_STATIC_MEMORY) path; in static mode iteration advances via the…
Fix: Correct the comment and guard the fan-out match on connection liveness.
Description