moxie25/nanomq-memory-leak-researchCVE-2026-36590 के लिए सार्वजनिक सलाह और तकनीकी विश्लेषण, जो NanoMQ v0.24.9 में एक सेवा-अस्वीकृत भेद्यता है।
इस रिपॉजिटरी में CVE-2026-36590 के लिए सार्वजनिक सलाह और तकनीकी विश्लेषण शामिल है, जो EMQ NanoMQ v0.24.9 को प्रभावित करने वाली एक सेवा अस्वीकार भेद्यता है।
यह रिपॉजिटरी CVE समीक्षा के लिए एक सुलभ तकनीकी संदर्भ प्रदान करने के लिए सार्वजनिक है। CVE-2026-36590 का अंतिम वर्गीकरण CVE टीम या संबंधित CNA द्वारा निर्धारित किया जाएगा।
NanoMQ टीम ने इस मुद्दे पर विवाद किया है और इसे कॉन्फ़िगरेशन-संबंधी माना है। यह रिपॉजिटरी तकनीकी साक्ष्य पर केंद्रित है, जिसमें पुनरुत्पादन सामग्री, ASAN परिणाम, रनटाइम लॉग और स्रोत-कोड विश्लेषण शामिल हैं।
/nanomq/nng/src/supplemental/mqtt/mqtt_qos_db_api.c/ nni_qos_db_setजब NanoMQ v0.24.9 को SQLite समर्थन के बिना बनाया जाता है, जबकि को के रूप में कॉन्फ़िगर किया गया है, तो QoS डेटाबेस पॉइंटर रह सकता है। MQTT QoS संदेश हैंडलिंग के दौरान, एक क्लोन किए गए संदेश संदर्भ को जारी किए बिना जल्दी लौट सकता है। बार-बार QoS > 0 MQTT PUBLISH संदेश निरंतर मेमोरी खपत का कारण बन सकते हैं, जिससे अंततः सेवा अस्वीकार हो सकती है।
sqlite.enabletrueNULLnni_qos_db_setयह मुद्दा एक गैर-डिफ़ॉल्ट रनटाइम कॉन्फ़िगरेशन पर निर्भर करता है, लेकिन निम्नलिखित तथ्य दिखाते हैं कि इसके लिए अभी भी आगे की समीक्षा की आवश्यकता क्यों है:
NanoMQ रनटाइम कॉन्फ़िगरेशन स्वीकार करता है और चलता रहता है, बजाय इसके कि यह रिपोर्ट करे कि वर्तमान बिल्ड में SQLite समर्थन उपलब्ध नहीं है।
यह कॉन्फ़िगरेशन बेमेल व्यवहार में हो सकता है। एक उपयोगकर्ता सामान्य बिल्ड कमांड के साथ NanoMQ बना सकता है, लेकिन बाद में एक उदाहरण कॉन्फ़िगरेशन फ़ाइल से SQLite दृढ़ता अनुभाग को कॉपी या सक्षम कर सकता है।
प्रभावित कोड पथ इस असंगत स्थिति को पूरी तरह से मान्य नहीं करता है। जब रनटाइम कॉन्फ़िगरेशन SQLite को सक्षम मानता है लेकिन डेटाबेस पॉइंटर NULL होता है, तो nni_qos_db_set() पास किए गए संदेश ऑब्जेक्ट को जारी किए बिना जल्दी लौटता है।
इस कॉन्फ़िगरेशन को स्वीकार करने के बाद, मुद्दा दूरस्थ MQTT ट्रैफ़िक द्वारा ट्रिगर किया जा सकता है। बार-बार QoS > 0 PUBLISH संदेश प्रभावित पथ में प्रवेश कर सकते हैं और संचित मेमोरी लीक का कारण बन सकते हैं।
1, 50 और 500 पुनरुत्पादन राउंड के साथ ASAN परीक्षण दिखाते हैं कि लीक हुए बाइट्स और आवंटन ट्रिगर प्रयासों की संख्या के साथ बढ़ते हैं। इससे पता चलता है कि मुद्दा इनपुट-गणना-निर्भर है, न कि एक बार का छोटा लीक।
उपयोगकर्ताओं को NanoMQ इंस्टेंस तक पहुंच प्रतिबंधित करनी चाहिए, MQTT सेवाओं को अविश्वसनीय क्लाइंट्स को उजागर करने से बचना चाहिए, और SQLite समर्थन के बिना बिल्ड में SQLite दृढ़ता को सक्षम करने से बचना चाहिए। विक्रेता को SQLite कॉन्फ़िगरेशन के लिए स्टार्टअप सत्यापन जोड़ना चाहिए और nni_qos_db_set के db == NULL शाखा में संदेश संदर्भ जारी करना चाहिए।
Docker/Docker_Reproduction_Guide.mdसारांश इस रिपॉजिटरी में NanoMQ में पाई गई मेमोरी लीक भेद्यता के लिए प्रूफ ऑफ कॉन्सेप्ट (PoC) और विस्तृत विश्लेषण शामिल है। यह मुद्दा दूरस्थ हमलावरों को विशिष्ट QoS MQTT संदेशों के माध्यम से सिस्टम मेमोरी को समाप्त करके सेवा अस्वीकार (DoS) करने की अनुमति देता है।
मैंने Nanomq में मेमोरी लीक की घटना का गहन विश्लेषण किया है। डायनामिक इंस्ट्रूमेंटेशन और कोड समीक्षा के माध्यम से, मैंने एक महत्वपूर्ण संसाधन लीक पथ की पहचान की जो तब ट्रिगर होता है जब रनटाइम कॉन्फ़िगरेशन SQLite को सक्षम करता है (sqlite.enable=true) लेकिन बाइनरी SQLite समर्थन के बिना संकलित की जाती है (NNG_SUPP_SQLITE अपरिभाषित)।
इस मुद्दे को संक्षिप्त रखने के लिए, मैंने मुख्य निष्कर्षों को नीचे संक्षेप में प्रस्तुत किया है। पूर्ण तकनीकी विवरण (विस्तृत ASAN ट्रेस, जीवनचक्र आरेख और इंस्ट्रूमेंटेशन लॉग सहित) के लिए, कृपया संलग्न Analysis_Report.md देखें।
AddressSanitizer का उपयोग करके, मैंने लीक हुई मेमोरी के स्रोत को tcptran_pipe_recv_cb (nng/src/sp/transport/mqtt/broker_tcp.c) के भीतर nni_msg_alloc पर इंगित किया। मेमोरी आवंटित की गई थी लेकिन पूरी तरह से जारी नहीं की गई।
मैंने nni_msg के संदर्भ गणना तंत्र का विश्लेषण किया। एक सामान्य QoS 1 संदेश जीवनचक्र में निम्नलिखित शामिल होना चाहिए:
चूंकि इस उच्च-समवर्ती परिदृश्य के लिए GDB अव्यावहारिक था, मैंने विशिष्ट मेमोरी ऑब्जेक्ट्स (जैसे, 0x60e00002ffa0) के जीवनचक्र को ट्रेस करने के लिए डायनामिक इंस्ट्रूमेंटेशन का उपयोग किया।
निष्कर्ष: लॉग ने जीवनचक्र बेमेल की पुष्टि की:
nmq_pipe_send_start_v4 में उत्पन्न क्लोन 2 से मेल खाती है।निष्पादन प्रवाह का पता लगाने से पता चला कि तीसरा फ्री क्यों लापता था:
-DNNG_SUPP_SQLITE के बिना संकलित किया गया था, जिससे nano_sock_setdb में प्रारंभिकरण तर्क हटा दिया गया। हालांकि, nanomq.conf में sqlite.enable = true था। इससे db पॉइंटर NULL बना रहा।nni_qos_db_set में प्रवेश करता है, तो फ़ंक्शन NULL पॉइंटर की जाँच करता है:// फ़ाइल: /nanomq/nng/src/supplemental/mqtt/mqtt_qos_db_api.c
void nni_qos_db_set(..., void *db, ..., nng_msg *msg) {
if (db == NULL) {
// महत्वपूर्ण दोष:
// प्रारंभिक वापसी इसलिए होती है क्योंकि db NULL है।
// फ़ंक्शन 'msg' का स्वामित्व रखता है (Ref++) लेकिन इसे जारी करने में विफल रहता है।
return;
}
// ...
}
फ़ंक्शन nni_msg_free(msg) को कॉल किए बिना चुपचाप लौटता है। इसके परिणामस्वरूप msg पॉइंटर अपरिवर्तनीय रूप से खो जाता है, जिससे मेमोरी ब्लॉक प्रभावी रूप से अनाथ हो जाता है।
nni_qos_db_set में रक्षात्मक प्रोग्रामिंग की कमी। यह अमान्य DB स्थिति के कारण प्रारंभिक वापसी करते समय msg पॉइंटर के स्वामित्व को संभालता नहीं है।सिफारिशें:
nano_sock_setdb या main फ़ंक्शन) के दौरान सत्यापन तर्क जोड़ें ताकि यह सुनिश्चित हो सके कि SQLite सही ढंग से चल रहा है। यदि conf->sqlite.enable == true का पता चलता है लेकिन NNG_SUPP_SQLITE मैक्रो अपरिभाषित है या SQLite असामान्य है, तो सिस्टम को या तो त्रुटि के साथ बाहर निकलना चाहिए या जबरन enable को false पर सेट करना चाहिए और एक चेतावनी प्रिंट करनी चाहिए।nni_qos_db_set फ़ंक्शन की प्रारंभिक वापसी शाखा में संसाधन रिलीज़ तर्क जोड़ें। यदि db == NULL है, तो संदर्भ गणना को संतुलित करने और मेमोरी लीक को रोकने के लिए nni_msg_free(msg) को कॉल किया जाना चाहिए।