NanoMQ TLS订阅功能中的堆释放后使用问题分析

问题背景

在NanoMQ项目的最新版本中，开发团队发现了一个关于TLS订阅功能的内存安全问题。当用户使用nanomq_cli工具进行TLS加密的MQTT订阅操作时，系统会出现"heap-use-after-free"错误，导致程序异常终止。这个问题虽然只在特定条件下触发，但可能影响系统的稳定性和安全性。

问题现象

用户执行以下命令时会出现问题：

./nanomq_cli/nanomq_cli sub -h 127.0.0.1 -p 8883 -t "topic3" --cafile ../etc/certs/cacert.pem -s

错误表现为地址消毒器(AddressSanitizer)检测到的堆释放后使用问题，具体发生在nni_atomic_dec_nv函数中。错误信息显示线程T20尝试写入已经被线程T6释放的内存区域。

技术分析

问题根源

通过分析错误堆栈和代码，可以确定问题的根本原因在于MQTT订阅消息的生命周期管理不当。具体表现为：

1. 在connect_cb回调函数中创建了订阅消息(nng_mqtt_subscribe)
2. 消息被发送到TLS传输层进行处理
3. 传输层在处理过程中释放了消息内存(mqtts_tcptran_pipe_send_cb)
4. 但上层代码仍尝试再次释放同一消息(nni_msg_free)

这种双重释放问题源于消息所有权管理不清晰，导致多个执行路径都认为自己负责消息的释放。

代码流程

问题涉及的主要代码流程如下：

1. 客户端初始化并建立TLS连接
2. 连接成功后触发connect_cb回调
3. 回调中创建订阅消息并发送
4. TLS传输层处理发送完成后释放消息
5. 上层代码再次尝试释放同一消息

解决方案

开发团队确认正确的做法应该是整个订阅消息的生命周期都由SDK统一管理。修复方案包括：

1. 明确消息所有权归属
2. 确保消息只被释放一次
3. 在传输层处理完成后不重复释放消息
4. 完善错误处理路径中的资源清理逻辑

问题重现方法

虽然这个问题在正常情况下不易出现，但可以通过在broker_tls.c文件中添加特定代码强制触发错误路径来重现问题：

rv = NNG_EPROTO;
log_error("Time to goto error");
goto recv_error;

这种人为干预可以帮助开发者验证修复方案的有效性。

总结

内存安全问题在异步、多线程的网络编程中尤为常见。NanoMQ团队通过这次问题的分析和修复，不仅解决了特定的堆释放后使用问题，也为类似场景下的资源管理提供了最佳实践。对于开发者而言，理解消息生命周期的管理、明确资源所有权是避免此类问题的关键。

该问题的修复体现了NanoMQ团队对代码质量的严格要求，确保了TLS加密通信场景下的系统稳定性。