Executive Summary

This vulnerability exists in NanoMQ MQTT Broker versions 0.24.10 and below. When the broker handles high-concurrency reconnect traffic using a reconnect-collision payload, it can crash due to a NULL pointer dereference during MQTT session resumption for clients with clean_start=0.

Specifically, the function tcptran_pipe_peer() iterates over a pointer called cpipe->subinfol while copying session metadata from the cached old connection to the new reconnecting connection without checking if the pointer is NULL. Under certain race conditions, cpipe->subinfol can be freed and set to NULL before this function is called, causing the broker process to crash.

This results in a remote unauthenticated Denial-of-Service (DoS) condition. The issue was fixed in version 0.24.11.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can cause the NanoMQ broker to crash remotely without authentication, leading to a Denial-of-Service (DoS) condition.

As a result, legitimate clients may be unable to connect or resume their MQTT sessions, disrupting messaging services and potentially causing downtime in systems relying on NanoMQ for edge messaging.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability causes a remote unauthenticated Denial-of-Service (DoS) condition by crashing the NanoMQ broker during MQTT session resumption. While it impacts availability, there is no indication from the provided information that it affects confidentiality or integrity of data.

Since the vulnerability leads to service disruption but does not expose or alter personal or sensitive data, its direct impact on compliance with standards like GDPR or HIPAA is limited to availability concerns.

Organizations relying on NanoMQ for critical messaging should consider the DoS risk as part of their availability and operational resilience controls, which are relevant to compliance frameworks that require maintaining service availability.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability causes the NanoMQ MQTT Broker to crash due to a NULL pointer dereference during MQTT session resumption when handling high-concurrency reconnect traffic. Detection can focus on monitoring for unexpected NanoMQ broker crashes or restarts, especially under high reconnect load.

You can check the NanoMQ broker logs for crash reports or errors related to the function `tcptran_pipe_peer()` or NULL pointer dereference events.

While no specific commands are provided in the resources, general commands to monitor the NanoMQ process status and logs include:

• Use `systemctl status nanomq` or `ps aux | grep nanomq` to check if the NanoMQ process is running.
• Use `journalctl -u nanomq` or check NanoMQ log files for crash or error messages.
• Monitor network traffic for high concurrency reconnect attempts to the MQTT broker, which may trigger the crash.

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation step is to upgrade NanoMQ to version 0.24.11 or later, where this NULL pointer dereference crash issue has been fixed.

Until the upgrade can be applied, consider limiting the concurrency of reconnect traffic to reduce the chance of triggering the race condition that causes the crash.

Monitor the NanoMQ broker for crashes and restart it promptly if it crashes to maintain service availability.

Useful 0 Not Useful 0