物联网消息队列后端【免费下载链接】mosquittoEclipse Mosquitto - An open source MQTT broker项目地址https://gitcode.com/gh_mirrors/mosquit/mosquitto点击查看免费下载2021 年 6 月 8 日Eclipse Mosquitto 同时发布了 2.0.11 与 1.6.15 两个版本二者均为安全与缺陷修复版本。本文将逐条解读该版本公告中的每一项修复内容并结合本仓库源码src/conf.c、src/bridge.c、src/database.c、client/sub_client.c 等说明其底层原理、触发条件与升级验证方法帮助运维与二次开发者判断升级必要性并理解相关配置项行为。版本概览与适用范围本次发布包含两个分支版本定位安全修复2.0.112.0 系列维护版安全 缺陷修复MQTT v5 CONNECT 内存泄漏1.6.151.6 系列维护版安全修复MQTT v5 CONNECT 内存泄漏同一漏洞两个版本共享同一个安全修复详见下文2.0.11 还额外包含了 Broker 与客户端工具的一批缺陷修复。如果你的部署仍停留在 1.6 分支仅需关注安全修复若运行 2.0 分支则建议完整评估 2.0.11 的全部变更。安全修复MQTT v5 伪造 CONNECT 触发内存泄漏公告原文指出如果使用 MQTT v5 连接的已认证客户端向 Broker 发送精心构造的 CONNECT 报文会导致内存泄漏。受影响版本为 1.6 至 2.0.10含。这是本次两个版本共同修复的唯一安全问题。触发前提是客户端已完成认证authenticated使用 MQTT v5 协议CONNECT 报文被“精心构造”crafted即包含异常的属性组合或编码。从源码结构看MQTT v5 的 CONNECT 报文与属性解析集中在 src/handle_connect.c 及 lib 侧协议数据解析逻辑中v5 引入的属性Properties字段允许动态长度编码与多种可选属性一旦属性长度、类型或字符串边界处理出现偏差就可能造成分配的内存未被释放。攻击者无需大量流量即可缓慢耗尽 Broker 内存属于典型的资源耗尽型风险。影响面与处置建议受影响版本1.6 至 2.0.10含 2.0.0~2.0.10、1.6.0~1.6.14。未受影响2.0.11、1.6.15 及之后版本。处置方式升级到 2.0.11 或 1.6.15对于无法立即升级的部署可结合防火墙限制 MQTT v5 客户端来源、监控 Broker 内存增长如$SYS树与系统监控作为临时缓解手段。Broker 稳定性修复2.0.111. per_listener_settings SIGHUP 组合崩溃#2167现象从 1.6 升级到 2.0.x 后如果配置了per_listener_settings true且在任一客户端重新连接 Broker 之前向其发送 SIGHUP 信号Broker 可能崩溃。原理per_listener_settings决定安全选项是按监听器独立还是全局生效。在 src/conf.c 的conf__set_cur_security_options()中可以看到开启该选项后安全选项对象被切换为当前监听器的security_options配置解析时 src/conf.c 还强制要求该选项必须出现在其他安全配置之前否则报错per_listener_settings must be set before any other security settings。SIGHUP 触发配置热重载的链路在 src/signals.cSIGHUP置位flag_reload随后主循环执行 src/signals.c 的重载流程config__read(db.config, true)重新读取配置并重建监听器与安全选项结构。在升级过渡期间若监听器集合尚未被客户端“激活/重连”重载路径中对监听器安全选项的引用就可能悬空从而崩溃。修复后该路径被加固升级后发送 SIGHUP 不再触发崩溃。配置示例注意顺序# 必须放在其他安全选项之前 per_listener_settings true listener 1883 allow_anonymous false password_file /etc/mosquitto/pwfile listener 8883 allow_anonymous true2. 桥接首次重连失败后不再重连#2207现象Bridge 第一次重连尝试失败后后续不再继续重连。原理Bridge 的重连由退避backoff逻辑驱动。src/bridge.c 的bridge__backoff_step()实现了 AWS 提出的 “Decorrelated Jitter” 指数退避算法bridge-restart_timeout rand_between(bridge-backoff_base, bridge-restart_timeout * 3); if(bridge-restart_timeout bridge-backoff_cap){ bridge-restart_timeout bridge-backoff_cap; }即每次重连超时在[backoff_base, 3 * 当前超时]区间内随机取值并受backoff_cap上限约束。修复前首次尝试失败可能导致restart_timeout计算路径异常从而令后续重连被跳过本次修复保证了失败后重连计时器始终会被正确调度桥接链路可自动恢复。此外 src/bridge.c 中非轮询模式round_robin false下主地址primary失败后会设置primary_retry db.now_s 5并在 5 秒后再次尝试。3. QoS 0 出站报文队列优化与 queue_qos0_messages 修复#2224本次修复包含两部分改进 QoS 0 出站报文的排队处理Improve QoS 0 outgoing packet queueing修复开启queue_qos0_messages后 QoS 0 消息仍不入队的问题。queue_qos0_messages的默认值为false见 src/conf.c解析入口在 src/conf.c。该配置的结构体成员定义于 src/mosquitto_broker_internal.h。其在消息投递链路中的语义非常明确src/database.cQoS 0 消息要么进入 in-flight 直接投递要么被丢弃除非客户端离线且开启了queue_qos0_messages否则不存在排队选项。具体判断逻辑db__ready_for_flight()src/database.c决定是否允许直接投递当max_queued_messages 0 max_inflight_bytes 0时无条件允许db__ready_for_queue()src/database.c决定是否允许入队QoS 0 且queue_qos0_messages false时直接返回 false即不排队。修复前存在配置开启后 QoS 0 消息仍被丢弃的缺陷#2224本次修复后只要配置queue_qos0_messages true离线客户端的 QoS 0 消息会与 QoS 1/2 一样进入持久化队列相关持久化回调在 src/plugin_persist.c 中同样以queue_qos0_messages作为是否持久化 QoS 0 的判据。配置示例# 为离线客户端保留 QoS 0 消息默认 false queue_qos0_messages true # 可配合队列上限使用 max_queued_messages 10004. Windows 平台修复#2172、#2173#2172不可达non-reachable的 Bridge 不再阻塞 Windows 上的整个 Broker。此前若 Bridge 目标地址无法连接可能因阻塞式解析/连接占用主循环导致其他客户端无法被服务。#2173Bridge 重连期间可能损坏pollfd数组pollfd array corruption。Windows 上事件驱动多路复用基于 src/mux_poll.c 的 poll 实现Bridge 反复重连时文件描述符集合的增删若与轮询数组不同步会造成数组损坏。本次修复保证重连过程中 pollfd 数组的一致性。客户端工具修复2.0.111. mosquitto_sub 检测管道关闭并断开#2164现象将mosquitto_sub输出通过管道pipe传给下游程序如mosquitto_sub ... | grep ...或| head当下游关闭管道后mosquitto_sub现在能检测到管道已关闭并主动断开连接。实现依据在 client/sub_client.c 的消息输出回调中打印消息后立即检查标准输出错误标志print_message(cfg, message, properties); if(ferror(stdout)){ mosquitto_disconnect_v5(mosq, 0, cfg.disconnect_props); }当管道写入失败ferror(stdout)为真时客户端主动调用mosquitto_disconnect_v5()断开与 Broker 的连接从而避免无效的空转输出循环。这在把订阅结果接入脚本/日志流水线时非常实用——下游管道关闭后订阅进程能及时退出而不是持续占用连接。2. mosquitto_pub -l 在 Broker 临时不可用时不再退出#2187现象修复前使用mosquitto_pub -l从标准输入逐行读取并发布时若某次发布恰好遇到 Broker 暂时不可用进程会直接退出导致后续行无法继续发布。-l模式的实现位于 client/pub_client.c 的pub_stdin_line_loop()该函数启动后台事件循环mosquitto_loop_start逐行读取 stdin 并通过发布回调发送。修复后单条消息发布失败如网络瞬时中断不再中断整个 stdin 读取循环客户端会等待重连后继续处理后续输入行。该修复对持续灌入数据的脚本类场景如日志转发、传感器数据批量上报意义明显。1.6.15仅含安全修复的维护版本1.6.15 与 2.0.11 共享唯一的安全修复MQTT v5 crafted CONNECT 内存泄漏影响 1.6~2.0.10不包含 2.0.11 中的 Broker 与客户端功能修复。仍在 1.6 分支的生产环境建议至少升级到 1.6.15以封堵内存泄漏漏洞如需获得桥接重连、QoS 0 队列等稳定性改进则应规划迁移至 2.0.11 或更新版本。升级与验证建议确认当前版本mosquitto -h输出第一行即版本号也可查看$SYS/broker/version主题。安全修复验证升级后使用 MQTT v5 客户端发送包含畸形属性的 CONNECT 报文观察 Broker 进程内存如ps -o rss或容器内存指标是否持续增长。升级前应能看到单调上升升级后应保持平稳。配置热重载回归若使用per_listener_settings true升级后依次执行“启动 Broker → 发送kill -HUP pid→ 客户端重连”三步确认无崩溃对应 #2167。桥接回归配置 bridge 并断开远端 Broker观察首次重连失败后是否仍会按退避策略继续重试对应 #2207Windows 部署可重点回归多 bridge 重连场景对应 #2172、#2173。QoS 0 队列回归配置queue_qos0_messages true让客户端离线后发布 QoS 0 消息重连后应能收到对应 #2224。相关配置项说明可查阅 man/mosquitto.conf.5.xml。客户端回归mosquitto_sub | head -1验证管道关闭后订阅进程退出#2164mosquitto_pub -l配合短暂中断的 Broker 验证不再退出#2187。小结Mosquitto 2.0.11 / 1.6.15 是一次以安全为核心的紧凑维护版本MQTT v5 crafted CONNECT 内存泄漏影响 1.6~2.0.10 全系列必须尽快升级2.0.11 同时修复了per_listener_settings SIGHUP 的升级崩溃、桥接重连停滞、QoS 0 消息排队失效以及 Windows 平台两个稳定性问题并改进了mosquitto_sub与mosquitto_pub -l的管道/断连行为。结合本文给出的源码路径src/conf.c、src/signals.c、src/bridge.c、src/database.c与验证步骤可快速评估并落地本次升级。赞分享物联网消息队列后端【免费下载链接】mosquittoEclipse Mosquitto - An open source MQTT broker项目地址https://gitcode.com/gh_mirrors/mosquit/mosquitto点击查看免费下载相关推荐Eclipse Mosquitto 2.0.11 安全与缺陷修复版本解析内存泄漏修复、QoS 0 队列与桥接稳定性Eclipse Mosquitto 2.0.11 安全与缺陷修复版本解析内存泄漏修复、QoS 0 队列与桥接稳定性 导读 本文基于 Mosquitto 官方发物联网消息队列后端网络/通信Eclipse Mosquitto 2.0.11 与 1.6.15 发布解析MQTT v5 内存泄漏修复与桥接重连可靠性提升Eclipse Mosquitto 2.0.11 与 1.6.15 发布解析MQTT v5 内存泄漏修复与桥接重连可靠性提升 导读 本文基于 Eclipse后端消息队列消息路由Mosquitto 2.0.3 发布详解mosquitto_passwd 安全漏洞修复与 Broker 稳定性改进Mosquitto 2.0.3 发布详解mosquitto_passwd 安全漏洞修复与 Broker 稳定性改进 Mosquitto 2.0.3 是 Ecl物联网消息队列后端网络/通信上一篇raytracing.github.io渲染质量采样数与渲染时间的平衡下一篇高性能移动端OCR文本检测PP-OCRv5_mobile_det_onnx跨平台解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Mosquitto 2.0.11 / 1.6.15 安全与稳定性修复详解：MQTT v5 CONNECT 内存泄漏、桥接重连与 QoS 0 队列改进
物联网消息队列后端【免费下载链接】mosquittoEclipse Mosquitto - An open source MQTT broker项目地址https://gitcode.com/gh_mirrors/mosquit/mosquitto点击查看免费下载2021 年 6 月 8 日Eclipse Mosquitto 同时发布了 2.0.11 与 1.6.15 两个版本二者均为安全与缺陷修复版本。本文将逐条解读该版本公告中的每一项修复内容并结合本仓库源码src/conf.c、src/bridge.c、src/database.c、client/sub_client.c 等说明其底层原理、触发条件与升级验证方法帮助运维与二次开发者判断升级必要性并理解相关配置项行为。版本概览与适用范围本次发布包含两个分支版本定位安全修复2.0.112.0 系列维护版安全 缺陷修复MQTT v5 CONNECT 内存泄漏1.6.151.6 系列维护版安全修复MQTT v5 CONNECT 内存泄漏同一漏洞两个版本共享同一个安全修复详见下文2.0.11 还额外包含了 Broker 与客户端工具的一批缺陷修复。如果你的部署仍停留在 1.6 分支仅需关注安全修复若运行 2.0 分支则建议完整评估 2.0.11 的全部变更。安全修复MQTT v5 伪造 CONNECT 触发内存泄漏公告原文指出如果使用 MQTT v5 连接的已认证客户端向 Broker 发送精心构造的 CONNECT 报文会导致内存泄漏。受影响版本为 1.6 至 2.0.10含。这是本次两个版本共同修复的唯一安全问题。触发前提是客户端已完成认证authenticated使用 MQTT v5 协议CONNECT 报文被“精心构造”crafted即包含异常的属性组合或编码。从源码结构看MQTT v5 的 CONNECT 报文与属性解析集中在 src/handle_connect.c 及 lib 侧协议数据解析逻辑中v5 引入的属性Properties字段允许动态长度编码与多种可选属性一旦属性长度、类型或字符串边界处理出现偏差就可能造成分配的内存未被释放。攻击者无需大量流量即可缓慢耗尽 Broker 内存属于典型的资源耗尽型风险。影响面与处置建议受影响版本1.6 至 2.0.10含 2.0.0~2.0.10、1.6.0~1.6.14。未受影响2.0.11、1.6.15 及之后版本。处置方式升级到 2.0.11 或 1.6.15对于无法立即升级的部署可结合防火墙限制 MQTT v5 客户端来源、监控 Broker 内存增长如$SYS树与系统监控作为临时缓解手段。Broker 稳定性修复2.0.111. per_listener_settings SIGHUP 组合崩溃#2167现象从 1.6 升级到 2.0.x 后如果配置了per_listener_settings true且在任一客户端重新连接 Broker 之前向其发送 SIGHUP 信号Broker 可能崩溃。原理per_listener_settings决定安全选项是按监听器独立还是全局生效。在 src/conf.c 的conf__set_cur_security_options()中可以看到开启该选项后安全选项对象被切换为当前监听器的security_options配置解析时 src/conf.c 还强制要求该选项必须出现在其他安全配置之前否则报错per_listener_settings must be set before any other security settings。SIGHUP 触发配置热重载的链路在 src/signals.cSIGHUP置位flag_reload随后主循环执行 src/signals.c 的重载流程config__read(db.config, true)重新读取配置并重建监听器与安全选项结构。在升级过渡期间若监听器集合尚未被客户端“激活/重连”重载路径中对监听器安全选项的引用就可能悬空从而崩溃。修复后该路径被加固升级后发送 SIGHUP 不再触发崩溃。配置示例注意顺序# 必须放在其他安全选项之前 per_listener_settings true listener 1883 allow_anonymous false password_file /etc/mosquitto/pwfile listener 8883 allow_anonymous true2. 桥接首次重连失败后不再重连#2207现象Bridge 第一次重连尝试失败后后续不再继续重连。原理Bridge 的重连由退避backoff逻辑驱动。src/bridge.c 的bridge__backoff_step()实现了 AWS 提出的 “Decorrelated Jitter” 指数退避算法bridge-restart_timeout rand_between(bridge-backoff_base, bridge-restart_timeout * 3); if(bridge-restart_timeout bridge-backoff_cap){ bridge-restart_timeout bridge-backoff_cap; }即每次重连超时在[backoff_base, 3 * 当前超时]区间内随机取值并受backoff_cap上限约束。修复前首次尝试失败可能导致restart_timeout计算路径异常从而令后续重连被跳过本次修复保证了失败后重连计时器始终会被正确调度桥接链路可自动恢复。此外 src/bridge.c 中非轮询模式round_robin false下主地址primary失败后会设置primary_retry db.now_s 5并在 5 秒后再次尝试。3. QoS 0 出站报文队列优化与 queue_qos0_messages 修复#2224本次修复包含两部分改进 QoS 0 出站报文的排队处理Improve QoS 0 outgoing packet queueing修复开启queue_qos0_messages后 QoS 0 消息仍不入队的问题。queue_qos0_messages的默认值为false见 src/conf.c解析入口在 src/conf.c。该配置的结构体成员定义于 src/mosquitto_broker_internal.h。其在消息投递链路中的语义非常明确src/database.cQoS 0 消息要么进入 in-flight 直接投递要么被丢弃除非客户端离线且开启了queue_qos0_messages否则不存在排队选项。具体判断逻辑db__ready_for_flight()src/database.c决定是否允许直接投递当max_queued_messages 0 max_inflight_bytes 0时无条件允许db__ready_for_queue()src/database.c决定是否允许入队QoS 0 且queue_qos0_messages false时直接返回 false即不排队。修复前存在配置开启后 QoS 0 消息仍被丢弃的缺陷#2224本次修复后只要配置queue_qos0_messages true离线客户端的 QoS 0 消息会与 QoS 1/2 一样进入持久化队列相关持久化回调在 src/plugin_persist.c 中同样以queue_qos0_messages作为是否持久化 QoS 0 的判据。配置示例# 为离线客户端保留 QoS 0 消息默认 false queue_qos0_messages true # 可配合队列上限使用 max_queued_messages 10004. Windows 平台修复#2172、#2173#2172不可达non-reachable的 Bridge 不再阻塞 Windows 上的整个 Broker。此前若 Bridge 目标地址无法连接可能因阻塞式解析/连接占用主循环导致其他客户端无法被服务。#2173Bridge 重连期间可能损坏pollfd数组pollfd array corruption。Windows 上事件驱动多路复用基于 src/mux_poll.c 的 poll 实现Bridge 反复重连时文件描述符集合的增删若与轮询数组不同步会造成数组损坏。本次修复保证重连过程中 pollfd 数组的一致性。客户端工具修复2.0.111. mosquitto_sub 检测管道关闭并断开#2164现象将mosquitto_sub输出通过管道pipe传给下游程序如mosquitto_sub ... | grep ...或| head当下游关闭管道后mosquitto_sub现在能检测到管道已关闭并主动断开连接。实现依据在 client/sub_client.c 的消息输出回调中打印消息后立即检查标准输出错误标志print_message(cfg, message, properties); if(ferror(stdout)){ mosquitto_disconnect_v5(mosq, 0, cfg.disconnect_props); }当管道写入失败ferror(stdout)为真时客户端主动调用mosquitto_disconnect_v5()断开与 Broker 的连接从而避免无效的空转输出循环。这在把订阅结果接入脚本/日志流水线时非常实用——下游管道关闭后订阅进程能及时退出而不是持续占用连接。2. mosquitto_pub -l 在 Broker 临时不可用时不再退出#2187现象修复前使用mosquitto_pub -l从标准输入逐行读取并发布时若某次发布恰好遇到 Broker 暂时不可用进程会直接退出导致后续行无法继续发布。-l模式的实现位于 client/pub_client.c 的pub_stdin_line_loop()该函数启动后台事件循环mosquitto_loop_start逐行读取 stdin 并通过发布回调发送。修复后单条消息发布失败如网络瞬时中断不再中断整个 stdin 读取循环客户端会等待重连后继续处理后续输入行。该修复对持续灌入数据的脚本类场景如日志转发、传感器数据批量上报意义明显。1.6.15仅含安全修复的维护版本1.6.15 与 2.0.11 共享唯一的安全修复MQTT v5 crafted CONNECT 内存泄漏影响 1.6~2.0.10不包含 2.0.11 中的 Broker 与客户端功能修复。仍在 1.6 分支的生产环境建议至少升级到 1.6.15以封堵内存泄漏漏洞如需获得桥接重连、QoS 0 队列等稳定性改进则应规划迁移至 2.0.11 或更新版本。升级与验证建议确认当前版本mosquitto -h输出第一行即版本号也可查看$SYS/broker/version主题。安全修复验证升级后使用 MQTT v5 客户端发送包含畸形属性的 CONNECT 报文观察 Broker 进程内存如ps -o rss或容器内存指标是否持续增长。升级前应能看到单调上升升级后应保持平稳。配置热重载回归若使用per_listener_settings true升级后依次执行“启动 Broker → 发送kill -HUP pid→ 客户端重连”三步确认无崩溃对应 #2167。桥接回归配置 bridge 并断开远端 Broker观察首次重连失败后是否仍会按退避策略继续重试对应 #2207Windows 部署可重点回归多 bridge 重连场景对应 #2172、#2173。QoS 0 队列回归配置queue_qos0_messages true让客户端离线后发布 QoS 0 消息重连后应能收到对应 #2224。相关配置项说明可查阅 man/mosquitto.conf.5.xml。客户端回归mosquitto_sub | head -1验证管道关闭后订阅进程退出#2164mosquitto_pub -l配合短暂中断的 Broker 验证不再退出#2187。小结Mosquitto 2.0.11 / 1.6.15 是一次以安全为核心的紧凑维护版本MQTT v5 crafted CONNECT 内存泄漏影响 1.6~2.0.10 全系列必须尽快升级2.0.11 同时修复了per_listener_settings SIGHUP 的升级崩溃、桥接重连停滞、QoS 0 消息排队失效以及 Windows 平台两个稳定性问题并改进了mosquitto_sub与mosquitto_pub -l的管道/断连行为。结合本文给出的源码路径src/conf.c、src/signals.c、src/bridge.c、src/database.c与验证步骤可快速评估并落地本次升级。赞分享物联网消息队列后端【免费下载链接】mosquittoEclipse Mosquitto - An open source MQTT broker项目地址https://gitcode.com/gh_mirrors/mosquit/mosquitto点击查看免费下载相关推荐Eclipse Mosquitto 2.0.11 安全与缺陷修复版本解析内存泄漏修复、QoS 0 队列与桥接稳定性Eclipse Mosquitto 2.0.11 安全与缺陷修复版本解析内存泄漏修复、QoS 0 队列与桥接稳定性 导读 本文基于 Mosquitto 官方发物联网消息队列后端网络/通信Eclipse Mosquitto 2.0.11 与 1.6.15 发布解析MQTT v5 内存泄漏修复与桥接重连可靠性提升Eclipse Mosquitto 2.0.11 与 1.6.15 发布解析MQTT v5 内存泄漏修复与桥接重连可靠性提升 导读 本文基于 Eclipse后端消息队列消息路由Mosquitto 2.0.3 发布详解mosquitto_passwd 安全漏洞修复与 Broker 稳定性改进Mosquitto 2.0.3 发布详解mosquitto_passwd 安全漏洞修复与 Broker 稳定性改进 Mosquitto 2.0.3 是 Ecl物联网消息队列后端网络/通信上一篇raytracing.github.io渲染质量采样数与渲染时间的平衡下一篇高性能移动端OCR文本检测PP-OCRv5_mobile_det_onnx跨平台解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考