한국어

CVE-2026-98432 अस्थायी शमन

यह रिपॉज़िटरी उन स्क्रिप्ट्स को रखती है जो Linux होस्ट पर IP विकल्प ले जाने वाले IPv4 TCP पैकेट्स को ड्रॉप करती हैं। SELinux/Smack NetLabel CIPSO लेबलिंग के बिना होस्ट्स पर, CVE-2026-98432 (एक Linux कर्नेल IPv4 TCP use-after-free) ऐसे पैकेट्स के बिना ट्रिगर नहीं हो सकता। यह एक अस्थायी शमन है, कोई फ़िक्स नहीं। इसका किसी वास्तविक एक्सप्लॉइट के विरुद्ध परीक्षण नहीं किया गया (कोई सार्वजनिक PoC नहीं है), और कोई भी विक्रेता इसका समर्थन नहीं करता। यदि आपका डिस्ट्रीब्यूशन पहले से ही एक फ़िक्स्ड कर्नेल प्रदान करता है, तो उसे इंस्टॉल करें, और यदि आपने इसे लागू किया था तो revert.sh चलाएँ। यदि नहीं, तो जाँचें कि शमन आपके होस्ट पर लागू होता है, फिर नीचे दिए गए चरणों के साथ इसे लागू करें और सत्यापित करें (लगभग 10 मिनट)। लेखक एक व्यक्तिगत प्रशासक है, कोई विक्रेता नहीं।

क्या यह आप पर लागू होता है

1. uname -r की तुलना फ़िक्स्ड स्थिर संस्करणों से करें: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 (फ़िक्स कमिट e3f33b0a1d89d738e2b913dab519226eaf76e15b)। किसी डिस्ट्रीब्यूशन कर्नेल में यह फ़िक्स किसी भिन्न संस्करण संख्या के अंतर्गत हो सकता है, इसलिए अपने विक्रेता के ट्रैकर को भी जाँचें।
2. CIPSO लेबलिंग की जाँच करें: cat /sys/kernel/security/lsm। यदि SELinux या Smack सूचीबद्ध है और आप CIPSOV4 मैपिंग के साथ NetLabel का उपयोग करते हैं, तो यह शमन उस पथ को कवर नहीं करता।
3. आवश्यकताओं की जाँच करें: root, systemd, और nft। OpenWrt का अपना पथ है (Files देखें)। OpenWrt के अतिरिक्त, systemd के बिना होस्ट्स कवर नहीं किए गए हैं।

गंभीरता: कर्नेल CNA CVSS 9.8 देता है। Red Hat, Oracle और SUSE 8.1 देते हैं, और Amazon 7.0 देता है। Anthropic ने सार्वजनिक रूप से MPTCP लिसनर वाले Linux सर्वरों के विरुद्ध एक रिमोट root एक्सप्लॉइट का वर्णन किया (2026-10-27)। 2026-10-29 तक किसी इन-द-वाइल्ड शोषण की सूचना नहीं मिली।

2026-10-29/30 तक डिस्ट्रीब्यूशन स्थिति (एक स्नैपशॉट, इसलिए अपने विक्रेता को जाँचें):

डिस्ट्रीब्यूशन	स्थिति
Ubuntu (सभी समर्थित रिलीज़)	कोई फ़िक्स्ड कर्नेल नहीं
RHEL 8/9/10	कोई फ़िक्स्ड कर्नेल नहीं
Proxmox VE	2026-10-30 को pve-kernel चेंजलॉग में इस CVE के लिए कोई प्रविष्टि नहीं थी
Debian, Oracle Linux UEK, कुछ SUSE, कुछ Amazon Linux	फ़िक्स उपलब्ध हैं

लागू करें

1. sudo ./mitigate.sh चलाएँ। यह इडेम्पोटेंट है (इसे दोबारा चलाने पर रूलसेट पुनः लोड होता है)। यह Files के अंतर्गत सूचीबद्ध फ़ाइलों को इंस्टॉल करता है, और यदि आप root नहीं हैं, यदि nft अनुपस्थित है, या यदि systemd अनुपस्थित है तो यह बाहर निकल जाता है।

2. आउटपुट की तुलना नीचे दिए गए संदर्भ से करें। पहली पंक्ति यह होनी चाहिए:

   svc=active enabled=enabled mptcp=0
   

   दोनों नियम इसका पालन करते हैं, एक inet तालिका में और एक bridge तालिका में।

3. यदि कोई सेवा MPTCP के साथ सुन रही है, तो उसे पुनः आरंभ करें। net.mptcp.enabled=0 केवल नए सॉकेट्स को प्रभावित करता है, इसलिए पहले से खुला MPTCP लिसनर तब तक MPTCP बना रहता है जब तक उसकी सेवा पुनः आरंभ न हो। sysctl प्रति नेटवर्क नेमस्पेस है, और mitigate.sh इसे केवल होस्ट नेमस्पेस के लिए सेट करता है।

4. यदि होस्ट LXC या Docker कंटेनर चलाता है, तो Containers के साथ जारी रखें।

प्रकाशित एक्सप्लॉइट ने MPTCP लिसनर्स को लक्षित किया था। रेस के लिए स्वयं MPTCP की आवश्यकता नहीं है (फ़िक्स विवरण से अनुमान)। MPTCP के बिना किसी होस्ट से पूरी तरह समझौता किया जा सकता है या नहीं, यह स्थापित नहीं है।

सत्यापित करें

लक्ष्य का SYN-ACK IP विकल्पों को प्रतिध्वनित करता है। जो क्लाइंट स्वयं यह शमन चलाता है, वह उस SYN-ACK को छोड़ देता है, इसलिए check-blocked.py "blocked" रिपोर्ट करता है, भले ही लक्ष्य अशमित हो। एक होस्ट पर मापा गया: लक्ष्य पर revert.sh के बाद, शमित क्लाइंट से check-blocked.py ने अभी भी ipopt FAIL TimeoutError प्रिंट किया, जबकि verify-synack.sh ने ipopt synack=5 दिखाया।

एक टूल चुनें:

1. यदि आपके पास इस शमन के बिना एक क्लाइंट है, तो वहाँ python3 check-blocked.py <host> <port> चलाएँ (root की आवश्यकता नहीं)। यह दो बार कनेक्ट होता है: पहले सादा, फिर IP_OPTIONS सॉकेट विकल्प के माध्यम से सेट किए गए IPv4 Record Route विकल्प के साथ।
2. यदि आप इसकी गारंटी नहीं दे सकते, तो किसी भी क्लाइंट पर sudo ./verify-synack.sh <ip> <port> चलाएँ (क्लाइंट पर root, tcpdump और python3 आवश्यक)। यह निश्चित स्रोत पोर्ट्स से एक सादा SYN और एक IP-विकल्प SYN भेजता है और tcpdump के साथ लक्ष्य के SYN-ACKs की गणना करता है।

फिर आउटपुट की तुलना उस टूल की तालिका से करें।

check-blocked.py (शमन के बिना क्लाइंट से):

आउटपुट	अर्थ
plain CONNECTED	सामान्य TCP काम करता है
ipopt FAIL TimeoutError	IP-विकल्प SYN छोड़ दिया गया, जैसा इच्छित था

verify-synack.sh:

आउटपुट	अर्थ
plain: CONNECTED synack=N | ipopt: TimeoutError synack=0	लक्ष्य शमित है
ipopt ... synack>=1	लक्ष्य शमित नहीं है (IP-विकल्प SYN का उत्तर दिया गया)

कर्नेल-स्तरीय परिणाम (एक Proxmox VE होस्ट, कर्नेल 7.0, 2026-10-30): शमन बंद होने पर, कमज़ोर कोड पथ प्रति पथ एक बार चला, WireGuard और LXC से LXC तक। इसके चालू होने पर, SYN टाइम आउट हो गया और पथ 0 बार चला। नमूना एक होस्ट पर 2 स्थितियों में 2 पथ हैं। ट्रेसिंग विधि docs/ANALYSIS.md में है (अंग्रेज़ी)।

कंटेनर

nftables स्थिति प्रति नेटवर्क नेमस्पेस है, इसलिए केवल होस्ट नियम कंटेनर नेमस्पेस की रक्षा नहीं करते। LXC कंटेनरों पर मापा गया: केवल होस्ट नियमों के साथ, कंटेनर के अंदर से उसके स्वयं के 127.0.0.1 या उसके स्वयं के IP पर एक IP-विकल्प SYN कनेक्ट हो गया। कंटेनर होस्ट कर्नेल साझा करते हैं, इसलिए किसी भी कंटेनर के अंदर का कोड इस तरह से कमज़ोर पथ तक पहुँच सकता था।

1. पहले होस्ट पर Apply पूरा करें।
2. होस्ट पर sudo ./inject-netns.sh चलाएँ। यह वही नियमसेट प्रत्येक चल रहे LXC कंटेनर (pct/lxc-info, Proxmox के माध्यम से) और प्रत्येक चल रहे Docker कंटेनर में लोड करता है (होस्ट-नेटवर्क कंटेनर छोड़ दिए जाते हैं)।
3. आउटपुट की तुलना तालिका से करें।

आउटपुट	अर्थ
ok lxc:<id> या ok docker:<id>	उस कंटेनर नेमस्पेस में नियमसेट लोड हुआ
injected=N failed=M	कुल, M को 0 होना चाहिए

इंजेक्शन स्थायी नहीं है। कंटेनर पुनः आरंभ होने पर यह खो जाता है, इसलिए पुनः आरंभ के बाद स्क्रिप्ट को फिर से चलाएँ। LXC कंटेनर के अंदर नेस्टेड Docker कंटेनरों के लिए स्क्रिप्ट उस LXC कंटेनर के अंदर चलानी होगी (मापा नहीं गया)।

मापा गया परिणाम: 5 Proxmox होस्ट्स में, 64 कंटेनर नेमस्पेस 0 विफलताओं के साथ इंजेक्ट किए गए। इंजेक्शन के बाद, वही परीक्षण टाइम आउट हो गया और कंटेनर नेमस्पेस का ड्रॉप काउंटर बढ़ गया।

यदि कुछ टूट जाए

इस शमन के हस्तक्षेप का लक्षण है एक TCP कनेक्शन जो अस्वीकार होने के बजाय हैंग (टाइम आउट) हो जाता है, साथ ही इसके आउटपुट में बढ़ता काउंटर:

nft list ruleset | grep counter

कमांड	प्रभाव
systemctl stop cve-2026-98432-mitigation	तुरंत बंद, रीबूट पर फिर से चालू हो जाता है
systemctl disable --now cve-2026-98432-mitigation	अभी और रीबूट्स के बीच बंद रहता है

परीक्षण किए गए होस्ट्स पर मापी गई संगतता: नियम अपनी अलग टेबल्स में रहते हैं और Docker, ufw, iptables-legacy NAT नियमों, तथा NetBird (WireGuard) रूटिंग के साथ सह-अस्तित्व में रहे। सामान्य TCP कनेक्शन हर परीक्षित पथ पर काम करते रहे। सामान्य संचालन के दौरान ड्रॉप काउंटर टेस्ट-पैकेट गिनती पर ही स्थिर रहे (कोई वैध ट्रैफ़िक मेल नहीं खाया) एक छोटी अवलोकन अवधि (घंटों में, दिनों में नहीं) के दौरान।

अनुमान, मापा नहीं गया: एक nftables.service जिसकी कॉन्फ़िग में flush ruleset हो, रीलोड होने पर टेबल्स को हटा देगा। इसकी जाँच करें, और ऐसे रीलोड के बाद mitigate.sh फिर से चलाएँ।

पैचिंग के बाद हटाएँ

1. ठीक किया गया कर्नेल बूट करें और uname -r से पुष्टि करें।
2. sudo ./revert.sh चलाएँ। यदि आप MPTCP को फिर से सक्षम करना चाहते हैं तो --mptcp जोड़ें।
3. आउटपुट की अंतिम पंक्ति की तुलना करें:

आउटपुट	अर्थ
remaining tables: 0	यूनिट अक्षम है, तीनों फ़ाइलें और दोनों टेबल्स चली गईं

सीमाएँ