in_mqtt: fix off-by-one in publish topic length validation

[saddamr3e]

AddressSanitizer, malformed PUBLISH that fills the connection buffer:

==ERROR: AddressSanitizer: heap-buffer-overflow READ of size 1
    #0 mqtt_handle_publish plugins/in_mqtt/mqtt_prot.c
address is 0 bytes after the 2048-byte connection buffer

mqtt_handle_publish() compares the 2-byte topic length (hlen) against frame_avail while conn->buf_pos still points at the length field's low byte, so frame_avail counts that byte as space for the topic. The buf_pos++ right after moves onto the topic, so a PUBLISH whose declared topic length equals frame_avail reads one byte past buf_frame_end; when the packet fills the buffer to buffer_size that byte is buf[buffer_size]. Moving the increment above the check makes frame_avail measure the actual topic space. Existing in_mqtt runtime tests still pass.

---

Enter [N/A] in the box, if an item is not applicable to your change.

Testing
Before we can approve your change; please submit the following in a comment:

• [N/A] Example configuration file for the change
• [N/A] Debug log output from testing the change
• [N/A] Attached Valgrind output that shows no leaks or memory corruption was found

Documentation

• [N/A] Documentation required for this feature

Backporting

• Backport to latest stable release.

---

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

Summary by CodeRabbit

• Bug Fixes
  • Improved handling of incoming MQTT PUBLISH messages by validating the topic length against the correct remaining buffer range.
  • This helps prevent malformed packets from being accepted and improves reliability when processing message topics and payloads.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: cf743f3f-56ab-4271-8db5-7be20d52a171

📥 Commits

Reviewing files that changed from the base of the PR and between a1e05fc and e6f05b6.

📒 Files selected for processing (1)

• plugins/in_mqtt/mqtt_prot.c

---

📝 Walkthrough

Walkthrough

The PUBLISH packet parsing in mqtt_handle_publish was adjusted so that conn->buf_pos advances past the 2-byte topic length field before frame_avail is recomputed and hlen is validated against the remaining buffer, aligning the validation window with the subsequent topic pointer.

Changes

MQTT PUBLISH Topic Parsing Fix

Layer / File(s)	Summary
Topic length validation reordering plugins/in_mqtt/mqtt_prot.c	Buffer position now advances past the topic length field before frame_avail and hlen validation are performed, instead of validating before advancing.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: edsiper, cosmo0920

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main fix in mqtt publish topic length validation.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[saddamr3e]

Closing this. On a closer read the topic bytes are only consumed in mqtt_data_append(), which is gated by the conn->buf_pos > conn->buf_frame_end + 1 check right above it (and by the packet-id length check for QoS > 0). Since buf_pos equals the byte after the topic, that guard already rejects any topic that would extend past buf_frame_end, so the length check here being one looser does not lead to an out-of-bounds read. Not worth the change on its own.