johnhsb/linux-tcp-uaf-cve-2026-98432CVE-2026-98432 (Linux IPv4 TCP inet_opt UAF): केवल-पढ़ने वाली डायग्नोस्टिक स्क्रिप्ट, बिना रीबूट nftables/sysctl शमन उपाय, Ansible रोलआउट और प्रतिक्रिया मार्गदर्शिका (EN/KO)
CVE-2026-98432 के लिए एक प्रतिक्रिया किट, जो Linux कर्नेल द्वारा TCP कनेक्शन सेट अप करने के लिए उपयोग किए जाने वाले कोड में एक मेमोरी-सुरक्षा बग है। इसमें तीन चीज़ें हैं:
iptables का उपयोग करते हुए, या जहाँ iptables अनुपस्थित है वहाँ nftables), कर्नेल-सेटिंग (sysctl) फ़ाइलें और Ansible प्लेबुक, सभी रीबूट के बिना लागू किए जाते हैं। डिफ़ॉल्ट मोड केवल पैकेटों की गिनती करता है।2026-11-03 तक लिखा गया। यहाँ दिया गया प्रत्येक शमन उपाय अस्थायी है और कर्नेल फ़िक्स का विकल्प नहीं है। कर्नेल अपडेट और रीबूट (या लाइवपैच) को अलग से शेड्यूल करें।
| README | गाइड | डायग्नोस्टिक स्क्रिप्ट | |
|---|---|---|---|
| 🇺🇸 अंग्रेज़ी (डिफ़ॉल्ट) | README.md | cve-2026-98432-guide.en.md | check_cve_2026_98432.sh |
| 🇰🇷 한국어 | README.ko.md | cve-2026-98432-guide.ko.md | check_cve_2026_98432_ko.sh |
iptables का उपयोग करता है और रीबूट की आवश्यकता नहीं है। सुरक्षित रहने के लिए, यह पहले केवल गिनती करके शुरू होता है; एक बार पुष्टि हो जाने के बाद कि कोई वैध ट्रैफ़िक प्रभावित नहीं है, ड्रॉप करने पर स्विच करें।TCP कनेक्शन अनुरोध के IP हेडर में — शायद ही कभी — IPv4 विकल्प नामक अतिरिक्त फ़ील्ड हो सकते हैं। कर्नेल कनेक्शन सेट अप होने के दौरान उन विकल्पों को मेमोरी में रखता है। जब यह सफ़ाई करता था, तो यह उस मेमोरी को तुरंत मुक्त कर देता था, भले ही कोई अन्य CPU कोर अभी भी उसे पढ़ रहा हो।
मुक्त हो चुकी मेमोरी का उपयोग करना use-after-free (UAF) कहलाता है। यदि इस बीच वहाँ कुछ और रख दिया गया है, तो कर्नेल गलत डेटा पढ़ता है, जिसके कारण हो सकता है:
| आइटम | विवरण |
|---|---|
| प्रभावित | Linux 4.4 और बाद के संस्करण, प्रत्येक शाखा के फ़िक्स किए गए संस्करण से पहले। IPv6 प्रभावित नहीं है |
| गंभीरता | Kernel CNA, Red Hat और Ubuntu द्वारा CVSS 9.8 (गंभीर)। SUSE, Amazon और Oracle इसे 8.1 आंकते हैं, क्योंकि CPU के बीच टाइमिंग रेस जीतना कठिन है |
| मूल कारण | कर्नेल की सुरक्षित-मुक्ति अवधि (RCU grace period) की प्रतीक्षा किए बिना मेमोरी मुक्त की गई। अपस्ट्रीम फ़िक्स: कमिट e3f33b0a1d89 (kfree → kfree_rcu) |
| फ़िक्स किए गए कर्नेल संस्करण | 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 या बाद का — वितरण कर्नेल के लिए, संस्करण संख्या नहीं, बल्कि यह जाँचें कि फ़िक्स शामिल है या नहीं |
शोषण: 2026-11-03 तक यह CISA KEV (शोषण के लिए ज्ञात कमज़ोरियों की सूची) में नहीं है, और वास्तविक दुनिया के हमलों की कोई रिपोर्ट नहीं मिली है। कई GitHub रिपॉज़िटरी खुद को "PoC" होने का दावा करती हैं; इनमें से कोई भी सत्यापित नहीं है — इन्हें प्रोडक्शन नेटवर्क पर न चलाएँ।
वितरण के अनुसार फ़िक्स किए गए कर्नेल (संस्करण और स्रोत गाइड §2.2 में)
| वितरण | स्थिति |
|---|---|
| RHEL 8 / 9 / 10 | ✅ 2026-11-01 को फ़िक्स किए गए कर्नेल जारी (RHSA-2026:93414 / 93412 / 93413)। OpenShift (RHCOS) नोड्स अभी तक फ़िक्स नहीं हुए हैं |
| Debian 12 / 13 | ✅ फ़िक्स हो गया (DSA-6568-1, DLA-4841-1, DLA-4850-1) |
| Amazon Linux 2 / 2023 | ✅ फ़िक्स हो गया। EKS/ECS-अनुकूलित AMI, Fargate और Bottlerocket को रोल आउट किया जा रहा है |
| Rocky Linux (CIQ RLC Pro / LTS) | ✅ CIQ-समर्थित हर वेरिएंट फ़िक्स हो गया। कम्युनिटी Rocky के लिए, Rocky Errata देखें |
| Ubuntu 22.04 / 24.04 / 26.04 / 26.10 | ⏳ प्रगति पर (2026-11-03 तक "कार्य प्रगति पर") |
| Ubuntu 16.04 / 18.04 / 20.04 | ⏳ मानक समर्थन समाप्त हो चुका है — केवल Ubuntu Pro (ESM) ग्राहकों के लिए फ़िक्स अपेक्षित हैं |
| SUSE, Oracle Linux, AlmaLinux, … | फ़िक्स की सूचना मिली है — प्रत्येक विक्रेता की अपनी सलाह देखें |
4. अब क्या करें में दिया गया डायग्नोस्टिक स्क्रिप्ट आपको सटीक निर्णय देता है। एक मोटे अनुमान के तौर पर:
किसी हमले के काम करने के लिए, ① सर्वर में कम से कम दो CPU कोर होने चाहिए (दो कोर को एक ही समय पर एक ही मेमोरी को छूना होता है), और ② हमलावर का पैकेट अपने IPv4 विकल्पों के साथ सुरक्षित रूप से सर्वर तक पहुँचना चाहिए।
| # | यदि सर्वर… | जोखिम | क्या करें |
|---|---|---|---|
| 1 | किसी आंतरिक VPC या Kubernetes नोड में है, मल्टी-कोर है, और उसमें MPTCP लिसनर है (कंटेनर सहित) | 🔴 रिमोट रूट | फ़ायरवॉल नियम और sysctl अभी लागू करें, और नोड कर्नेल पैच करें। कुछ Kubernetes नेटवर्क (eBPF-आधारित CNI) होस्ट फ़ायरवॉल को बायपास करते हैं, इसलिए पैचिंग पहले करें |
| 2 | सार्वजनिक IP पर है या L4 लोड बैलेंसर (AWS NLB, …) के पीछे है और उसमें MPTCP लिसनर है | 🔴 रिमोट रूट | फ़ायरवॉल नियम और sysctl अभी लागू करें |
| 3 | मल्टी-कोर है और उसमें केवल सामान्य TCP सेवाएँ हैं | 🟠 रिमोट क्रैश | फ़ायरवॉल नियम लागू करें (अकेले sysctl मदद नहीं करता) |
| 4 | सिंगल CPU (एक vCPU) | 🟡 सफल होने की बहुत कम संभावना | नियमित पैच चक्र में शामिल करें |
| 5 | केवल L7 प्रॉक्सी (AWS ALB, CloudFront, Cloudflare, …) के माध्यम से पहुँच योग्य है और आंतरिक पहुँच नियंत्रित है | 🟡 हमले के पैकेट कभी नहीं पहुँचते | आंतरिक हमलावरों से बचाव के लिए पैच करें |
⚠️ यह निष्कर्ष न निकालें कि "कोई MPTCP लिसनर नहीं है, इसलिए हम सुरक्षित हैं।" Red Hat कहता है कि MPTCP लिसनर की जाँच करना "आश्वासन के बजाय सूचनात्मक" है। MPTCP के बिना भी क्रैश संभव है, और ऐसी अन्य शोषण विधि से इनकार नहीं किया जा सकता जिसे MPTCP की आवश्यकता न हो। साथ ही, RHEL 8-परिवार के कर्नेल पर
ss -MMPTCP लिसनर को सामान्य TCP के रूप में दिखा सकता है।
💡 L4 बनाम L7: एक L7 प्रॉक्सी क्लाइंट का TCP कनेक्शन समाप्त करता है और आपके सर्वर से एक नया कनेक्शन खोलता है, इसलिए हमलावर के IPv4 विकल्प उस तक कभी नहीं पहुँचते। एक L4 लोड बैलेंसर (AWS NLB TCP लिसनर, Global Accelerator, PrivateLink, VPC Lattice, …) पैकेट को बिना बदले आगे भेजता है, जो सर्वर को सीधे उजागर करने के समान है।
एक रीड-ओनली स्क्रिप्ट जो पैच स्थिति, शमन उपायों और जोखिम (कंटेनर सहित) की जाँच करती है और आपको जोखिम स्तर बताती है।