CVE-2026-98432 Linux कर्नेल के IPv4 TCP कनेक्शन-हैंडशेक कोड में मौजूद एक गंभीर use-after-free race है। यह कर्नेल संस्करण 4.4 और उसके बाद के संस्करणों को प्रभावित करती है और इसका CVSS 3.1 स्कोर 9.8 है। रिपोर्ट किए गए remote-root प्रदर्शन में Multipath TCP (MPTCP) listener वाला सर्वर इस्तेमाल हुआ था, लेकिन मूल खामी IPv4 TCP हैंडलिंग में है—यह केवल MPTCP की समस्या नहीं है।
6
44
57
यह फर्क अहम है: MPTCP से जुड़ा कोई अस्थायी उपाय रिपोर्ट में दिखाए गए खास रास्ते को रोक सकता है, लेकिन वह कर्नेल की खामी ठीक नहीं करता। शोधकर्ताओं ने remote code execution का प्रदर्शन बताया है, पर उपलब्ध साक्ष्य यह साबित नहीं करते कि इंटरनेट से जुड़े हर TCP सर्वर पर इसका भरोसेमंद ढंग से फायदा उठाया जा सकता है या हमलावरों ने वास्तविक सिस्टमों पर इसका सफल इस्तेमाल किया है।
37
55
यह race use-after-free कैसे बनती है?
कनेक्शन बनते समय Linux लंबित TCP अनुरोध से जुड़े IPv4 options को अस्थायी रूप से सहेजता है। हैंडशेक आगे बढ़ने पर tcp_v4_syn_recv_sock() इन options का स्वामित्व नए child socket को दे देता है—बिना उनकी कॉपी बनाए। उसी दौरान दूसरा CPU उसी अनुरोध के लिए दोबारा आए SYN पैकेट को संसाधित कर सकता है। अगर कनेक्शन खत्म होते समय options की मेमोरी मुक्त हो जाए, लेकिन दूसरा CPU अभी भी उसे पढ़ रहा हो, तो SYN-ACK बनाते वक्त वह मुक्त हो चुकी मेमोरी तक पहुंच सकता है।
44
यही use-after-free है: कर्नेल कोड ऐसी मेमोरी का इस्तेमाल जारी रखता है जिसकी अवधि समाप्त हो चुकी है। बताए गए संभावित नतीजों में सिस्टम क्रैश और मेमोरी करप्शन शामिल हैं; सुरक्षा सलाहों में remote code execution की संभावना भी बताई गई है। हालांकि, इस समस्या को भरोसेमंद तरीके से कोड चलाने में बदल पाना परिस्थितियों पर निर्भर करता है। MPTCP पर किया गया प्रदर्शन एक गंभीर exploit path का संकेत है, यह सबूत नहीं कि हर प्रभावित होस्ट को उसी तरह हैक किया जा सकता है।
52
55
कर्नेल पैच मेमोरी के जीवनकाल की समस्या को ठीक करता है: IPv4 options को RCU grace period के बाद मुक्त किया जाता है, ताकि समानांतर में उन्हें पढ़ रहा कोड अपना काम पूरा कर सके।
44
exploit रिपोर्ट से क्या पता चलता है—और क्या नहीं
Anthropic की 27 अक्टूबर की शोध रिपोर्ट को बाद की कवरेज में ऐसे प्रदर्शन के रूप में बताया गया जिसमें AI मॉडल ने MPTCP listener उपलब्ध कराने वाले सर्वर के लिए remote-root exploit बनाया था। रिपोर्टों के मुताबिक, exploit कोड और उसका कॉन्फ़िगरेशन सार्वजनिक नहीं किए गए। इससे प्रदर्शन की स्वतंत्र जांच और उसकी आवश्यक शर्तों का आकलन सीमित रहता है।
9
11
Matt Corallo ने कुछ Linux वितरणों में पैच उपलब्ध होने के बाद भी Ubuntu के सुधार परीक्षण में रहने की आलोचना की। उनकी टिप्पणी नियमित अपडेट में देरी को लेकर चिंता दिखाती है; यह अपने आप में वास्तविक exploit होने का अलग तकनीकी सबूत नहीं है।
12
सुरक्षा शोधकर्ता Marcus Hutchins ने प्रभावित सिस्टम खोजने के लिए संभावित स्कैनिंग गतिविधि की सूचना दी। स्कैनिंग से हमलावरों की दिलचस्पी और संभावित लक्ष्य तलाशने का संकेत मिलता है, लेकिन इससे यह साबित नहीं होता कि कोई सिस्टम सफलतापूर्वक हैक हुआ।
31
55 उपलब्ध स्रोतों से लगभग 21 लाख MPTCP-reachable सर्वरों के प्रसारित अनुमान की स्वतंत्र पुष्टि नहीं होती। इसलिए इसे प्रभावित या exploit किए जा सकने वाले होस्टों की पक्की संख्या नहीं मानना चाहिए।
MPTCP बंद करना सिर्फ अस्थायी उपाय क्यों है?
MPTCP यानी Multipath TCP, TCP कनेक्शन को एक से अधिक नेटवर्क पथों पर चलाने की सुविधा देता है। Go 1.24 और उसके बाद के संस्करणों में, अगर कर्नेल MPTCP का समर्थन करता है, तो listener इसे सक्षम कर सकते हैं। इसलिए किसी ऐप की नेटवर्किंग का व्यवहार MPTCP से प्रभावित हो सकता है, भले ही ऐप खास तौर पर MPTCP के लिए न लिखा गया हो।
37
Lightning Labs ने अपने LND रिलीज़ नोट्स में Linux ऑपरेटरों को MPTCP बंद करने और पैच किया हुआ कर्नेल इंस्टॉल करने की सलाह दी है। lnd v0.21.6-beta रिलीज़ में MPTCP listeners डिफ़ॉल्ट रूप से बंद हैं, जिससे उस ऐप के जरिए दिखाया गया exploit path बंद होता है। रिलीज़ नोट्स यह भी स्पष्ट करते हैं कि यह mitigation है, कर्नेल पैच का विकल्प नहीं।
33
37
ऐप के स्तर पर MPTCP बंद करने से उस ऐप का जोखिम घट सकता है; पूरे होस्ट पर इसे बंद करने से दूसरे MPTCP listeners भी प्रभावित हो सकते हैं। लेकिन इनमें से कोई भी तरीका मूल IPv4 TCP memory-lifetime खामी को ठीक नहीं करता। पैच आने तक इन्हें जोखिम घटाने के उपाय समझें—इस बात का प्रमाण नहीं कि बिना पैच वाला कर्नेल सुरक्षित है।
6
37
44
4 नवंबर तक रिपोर्ट की गई पैच स्थिति
पैच की उपलब्धता Linux वितरण के अनुसार अलग-अलग थी। Canonical ने 2 नवंबर को बताया कि Ubuntu 22.04 LTS और उसके बाद के संस्करणों के सुधार वैकल्पिक -proposed चैनल में थे और परीक्षण जारी था। कंपनी ने इसे अपनी जांच प्रक्रिया का हिस्सा बताया। उसी समय की रिपोर्टिंग के अनुसार, Red Hat ने 1 नवंबर को RHEL 8, 9 और 10 के लिए पैच किए हुए कर्नेल जारी किए थे।
6
7
परीक्षण के लिए पैच उपलब्ध होने और सामान्य अपडेट चैनल में पहुंचने के बीच के अंतर पर आलोचना हुई—खासकर remote-root प्रदर्शन की खबर के बाद। चिंता समझ में आती है, लेकिन पैच की स्थिति समय के साथ बदलती है। इसलिए अपने वितरण और संस्करण की सुरक्षा सलाह जांचें; यह न मानें कि किसी दूसरे वितरण का अपडेट आपके सिस्टम पर लागू होता है।
7
12
ऑपरेटरों के लिए प्राथमिकता यह जांचना है कि हर वर्कलोड पर वास्तव में कौन-सा कर्नेल चल रहा है, और उपलब्ध होते ही वितरण का पैच किया हुआ कर्नेल इंस्टॉल करना है। इस बीच MPTCP पर पाबंदी जोखिम घटा सकती है, लेकिन कमजोर memory-handling व्यवहार को केवल कर्नेल अपडेट ही ठीक करता है।
6
37
44