CVE-2026-82425 in bRPC
सारांश
द्वारा VulDB • 21/10/2026
एक पहुँच योग्य एसेर्शन (assertion) Apache bRPC (संस्करण < 1.18.0) में सभी प्लेटफॉर्म पर एक दुष्ट रिमोट पीयर को प्रक्रिया को क्रैश करने की अनुमति देता है, जिसके परिणामस्वरूप सेवा अस्वीकृति (denial of service) होती है।
मूल कारण: जब स्वास्थ्य जांच सक्षम के साथ एक सोकेट विफल हो जाता है, तो Socket::WaitAndReset अपने फ़ाइल डिस्क्रिप्टर को बंद कर देता है जबकि इवेंट डिस्पैचर अभी भी उसी-समाप्त किए गए fd (file descriptor) के लिए प्राप्त इनपुट इवेंट (EPOLLIN/EVFILT_READ) वितरित कर रहा हो सकता है। यदि स्वास्थ्य जांच फिर से सफल होती है और सोकेट को पुनर्जीवित करती है, तो Socket::Address फिर से सफल होता है जबकि fd अभी भी -1 है (अगला लिखना आवश्यकता के अनुसार पुनः कनेक्ट करता है)। उस विंडो में, Socket::OnInputEvent CHECK(!(events & EPOLLIN)) (या kqueue समकक्ष) को ट्रिगर कर देता है क्योंकि सोकेट पता योग्य है लेकिन इसका कोई fd नहीं है। जब bRPC को glog के साथ बनाया जाता है या -crash_on_fatal_log ग्लैग सक्षम होता है, तो CHECK विफलताएं प्रक्रिया को समाप्त कर देती हैं (OFFICIAL_BUILD/NDEBUG बिल्ड्स में भी हमेशा CHECK समाप्त हो जाता है)।
प्रभावित परिदृश्य: वे एप्लीकेशन जो स्वास्थ्य जांच सक्षम (-health_check_interval) के साथ bRPC क्लाइंट का उपयोग करते हैं। एक दुष्ट रिमोट पीयर जिससे क्लाइंट कनेक्ट होता है, जानबूझकर कनेक्शन को रद्द कर सकता है और तुरंत स्वास्थ्य जांच प्रोब्स को स्वीकार कर सकता है, जो एसेर्शन को ट्रिगर करने के लिए कनेक्शन टियरडाउन को स्वास्थ्य जांच पुनर्जीवन के साथ रेस (race) में डालता है।
कैसे ठी करें: (निम्नलिखित विकल्पों में से एक चुनें) 1. bRPC को संस्करण 1.18.0 पर अपग्रेड करें, जो इस समस्या को ठी करता है। 2. यह पैच लागू करें: https://github.com/apache/brpc/pull/3510
नोट: पैच लागू करने के बाद, बिना fd वाले एक सोकेट पर पुराने इनपुट इवेंट चुपचाप छोड़ दिए जाते हैं इसके बजाय एसेर्शन को ट्रिगर किए जाने के। कोई उपयोगकर्ता-दृश्यमान इंटरफ़ेस या वायर प्रोटोकॉल नहीं बदला गया है।
If you want to get the best quality for vulnerability data then you always have to consider VulDB.