Ubuntu और Debian के लिए CVE-2026-98432 अस्थायी शमन

एक एकल idempotent स्क्रिप्ट जो IP विकल्प ले जाने वाले आने वाले IPv4 TCP पैकेट्स को गिरा देती है, रीबूट के बाद भी नियम बनाए रखती है, और जाँचती है कि यह काम करता है। यह Ubuntu (18.04 – 24.04) और Debian (11 – 13) सर्वर के लिए है जिन्हें अभी तय किया गया कर्नेल नहीं मिल सकता।

यह एक अस्थायी उपाय है, समाधान नहीं। एकमात्र वास्तविक समाधान पैच किया गया कर्नेल और रीबूट है। सर्वर पर तय किया गया कर्नेल चलने के बाद इस शमन को हटा दें।

उपयोग

curl -fsSL https://raw.githubusercontent.com/Mervent/cve-2026-98432/master/install.sh | sudo sh

आप इसे कितनी भी बार चला सकते हैं: फ़ाइलें ओवरराइट हो जाती हैं और नियम कभी डुप्लिकेट नहीं होता। अंत में स्क्रिप्ट परिणाम को मान्य करती है और किसी भी विफलता पर गैर-शून्य के साथ बाहर निकलती है:

--- validation ---
OK    helper installed: /usr/local/sbin/cve-2026-98432-mitigation
OK    cron entry: /etc/cron.d/cve-2026-98432
OK    cron service enabled
OK    iptables rule active (raw/PREROUTING)
OK    exactly one rule (no duplicates)
      plain SYN: connected, SYN with IP options: timeout
OK    drop test: packets with IP options are dropped
--- rule counters ---
 pkts bytes target     prot opt in     out     source               destination
    3   204 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            u32 "0x0>>0x18&0xf=0x6:0xf" /* cve-2026-98432 */

यह क्या इंस्टॉल करता है

पथ	उद्देश्य
/usr/local/sbin/cve-2026-98432-mitigation	वह हेल्पर जो नियम रखता है। बिना किसी आर्ग्युमेंट के यह नियम जोड़ देता है यदि वह अनुपस्थित हो। --check यदि नियम सक्रिय है तो 0 के साथ बाहर निकलता है। --remove इसे हटा देता है।
/etc/cron.d/cve-2026-98432	@reboot प्रविष्टि जो हर बूट के बाद नियम को फिर से लागू करती है

नियम स्वयं:

iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0xF=6:15" \
    -m comment --comment cve-2026-98432 -j DROP

रीबूट के बाद जाँचें

sudo /usr/local/sbin/cve-2026-98432-mitigation --check && echo active
sudo iptables -t raw -L PREROUTING -v -n | grep cve-2026-98432

निश्चित कर्नेल में बूट करने के बाद हटाएँ

sudo /usr/local/sbin/cve-2026-98432-mitigation --remove
sudo rm /usr/local/sbin/cve-2026-98432-mitigation /etc/cron.d/cve-2026-98432

अपने वितरण में फ़िक्स शामिल है या नहीं, यह देखने के लिए Ubuntu या Debian देखें (Debian 9 – 11 के लिए, Freexian ELTS tracker)। एक बार आपका रिलीज़ "Fixed" दिखाने लगे, तो apt update && apt full-upgrade चलाएँ, रीबूट करें, फिर मिटिगेशन हटा दें।

1 नवंबर 2026 तक, Debian 12 (linux 6.1.190-1, DLA-4841-1) और Debian 13 (linux 6.12.113-1, DSA-6568-1) में पहले से ही फ़िक्स किए गए कर्नेल हैं, इसलिए उन रिलीज़ पर इस स्क्रिप्ट का उपयोग करने के बजाय अपग्रेड करें। Debian 11 का फ़िक्स (linux 5.10.272-1, ELA-1846-1) केवल Freexian के ELTS रिपॉज़िटरी में है: व्यावसायिक, लेकिन व्यक्तियों और छोटे गैर-लाभकारी संगठनों के लिए अनुरोध पर मुफ़्त।

तर्क

भेद्यता

CVE-2026-98432 ("ipv4: free inet_opt and ireq_opt after an RCU grace period") IPv4 TCP हैंडशेक में एक use-after-free है। यह Linux 4.4 और उसके बाद के संस्करणों को प्रभावित करता है और इसकी CVSS रेटिंग 9.8 है।

यदि किसी SYN में IPv4 विकल्प होते हैं, तो कर्नेल उन्हें request socket पर सहेजता है ताकि वह उन्हें SYN-ACK में वापस भेज सके। फिर tcp_v4_syn_recv_sock() उस बफ़र को कॉपी किए बिना चाइल्ड सॉकेट को सौंप देता है। जब चाइल्ड सॉकेट समाप्त हो जाता है, तो बफ़र को साधारण kfree() से मुक्त कर दिया जाता है, जबकि कोई अन्य CPU अभी भी पुनःप्रेषित SYN के लिए SYN-ACK बनाने हेतु उसे पढ़ रहा हो सकता है।

यह सब कर्नेल में होता है, इससे पहले कि कोई एप्लिकेशन कनेक्शन देखे। कोई भी सुनने वाला IPv4 TCP पोर्ट इस तरह पहुँच योग्य है (SSH, HTTP, PostgreSQL इत्यादि), और किसी क्रेडेंशियल की आवश्यकता नहीं है। Anthropic ने उन होस्ट्स के विरुद्ध एक कार्यशील रिमोट-रूट एक्सप्लॉइट की रिपोर्ट दी जिनमें multipath TCP (MPTCP) लिसनर है। Go Security Team नोट करती है कि यह बग MPTCP-विशिष्ट नहीं है।

IP विकल्पों वाले TCP पैकेट क्यों गिराएँ

जो मेमोरी बहुत जल्दी मुक्त हो जाती है, वह केवल तभी मौजूद होती है जब आने वाले SYN में IPv4 विकल्प हों। विकल्प न होने पर कोई सहेजा गया बफ़र नहीं होता, इसलिए use-after-free के पास कार्रवाई करने के लिए कुछ नहीं होता। वैध TCP ट्रैफ़िक व्यावहारिक रूप से कभी IPv4 विकल्प नहीं रखता, इसलिए उन पैकेटों को गिराने की व्यवहार में कोई लागत नहीं है। Red Hat (RHSB-2026-016) और AlmaLinux एक समतुल्य nftables नियम प्रकाशित करते हैं।

u32 "0>>24&0xF=6:15" IHL फ़ील्ड पढ़ता है, जो 32-बिट शब्दों में IPv4 हेडर की लंबाई है। 5 का मान केवल 20-बाइट हेडर है। 6 से 15 तक के मान का अर्थ है कि विकल्प मौजूद हैं।

Red Hat कहता है कि ऐसा नियम "इस भेद्यता के प्रति जोखिम को कम करता है लेकिन इसे पूरी तरह रोक नहीं सकता"। जब तक कर्नेल पैच न हो जाए, इसे जोखिम में कमी के रूप में ही लें।

raw / PREROUTING क्यों

• PREROUTING हर आने वाले पैकेट को देखता है, दोनों होस्ट तक जाने वाले ट्रैफ़िक और प्रकाशित पोर्ट्स पर Docker कंटेनरों को फ़ॉरवर्ड किए गए ट्रैफ़िक को। INPUT में एक नियम, जहाँ ufw अपने नियम रखता है, फ़ॉरवर्ड किए गए ट्रैफ़िक को छोड़ देगा।
• raw टेबल कनेक्शन ट्रैकिंग से पहले चलता है, इसलिए गिराए गए पैकेट कभी conntrack प्रविष्टियाँ नहीं बनाते।
• ufw और Docker raw/PREROUTING को फ़्लश नहीं करते, इसलिए नियम उनके रीस्टार्ट के बाद भी बना रहता है।

nftables के बजाय iptables क्यों

• iptables हर Ubuntu लक्ष्य रिलीज़ पर मौजूद है। Ubuntu 18.04 और 20.04 पर यह legacy बैकएंड का उपयोग करता है; Ubuntu 22.04 से और Debian 11+ पर यह iptables-nft है। nft बाइनरी हर जगह डिफ़ॉल्ट रूप से इंस्टॉल नहीं होती। Debian पर, iptables स्वयं अनुपस्थित हो सकता है; तब स्क्रिप्ट आपसे apt install iptables चलाने के लिए कहती है।
• iptables-nft के साथ, ufw/Docker और यह नियम nf_tables बैकएंड साझा करते हैं, इसलिए एक नियम दोनों को कवर करता है।
• u32 मैच के लिए xt_u32 कर्नेल मॉड्यूल आवश्यक है। यदि यह अनुपस्थित है, तो स्क्रिप्ट विफल हो जाती है और आपको modinfo xt_u32 जाँचने के लिए कहती है।

cron @reboot प्रविष्टि क्यों

• nftables.service नहीं। Ubuntu पर /etc/nftables.conf flush ruleset से शुरू होता है, और सेवा रुकने पर nft flush ruleset चलाती है। इनमें से कोई भी ufw और Docker नियमों को मिटा देता है।
• iptables-persistent नहीं। netfilter-persistent save हर मौजूदा नियम को डंप करता है, Docker के नियमों सहित, और बूट पर उस स्नैपशॉट को बहाल करना Docker द्वारा स्वयं बनाए गए नियमों से टकराता है।
• ufw before.rules नहीं। यह केवल तब काम करता है जब ufw सक्षम हो, और इसकी चेन कंटेनरों तक फ़ॉरवर्ड होने वाले ट्रैफ़िक को नहीं देखतीं।
• cron.d। यह मानक Ubuntu और Debian सर्वरों पर इंस्टॉल होता है (स्क्रिप्ट इसकी जाँच करती है), /etc/cron.d में एक फ़ाइल ओवरराइट द्वारा इडेम्पोटेंट होती है, और इसे हटाना एक rm है। इसका नुकसान बूट के बाद कुछ सेकंड की वह खिड़की है जब नेटवर्क चालू होता है लेकिन cron ने अभी नियम लागू नहीं किया होता। यह उस शमन के लिए स्वीकार्य है जिसे केवल अगले कर्नेल अपडेट तक टिकना है।

केवल net.mptcp.enabled=0 क्यों नहीं

MPTCP अक्षम करना एक प्रकाशित एक्सप्लॉइट की पूर्व-शर्त को हटाता है, बग को नहीं। सादे TCP लिसनर अभी भी उसी भेद्य कोड से गुज़रते हैं। MPTCP लिसनर रहित सर्वर पर (ss -Mlnp कुछ भी प्रिंट नहीं करता) sysctl कुछ भी नहीं बदलता। यह एक हानिरहित अतिरिक्त है, इस नियम का विकल्प नहीं।

सत्यापन

स्क्रिप्ट जाँचती है कि हेल्पर और cron प्रविष्टि इंस्टॉल हैं, cron सक्षम है, और ठीक एक नियम सक्रिय है। फिर यह python3 के साथ एक एंड-टू-एंड ड्रॉप परीक्षण चलाती है, जिसे python3 अनुपस्थित होने पर छोड़ दिया जाता है:

1. यह 127.0.0.1 पर एक लिसनर खोलती है।
2. यह एक बार IP विकल्पों के बिना कनेक्ट करती है; यह कनेक्शन सफल होना चाहिए।
3. यह एक बार Record Route IP विकल्प के साथ कनेक्ट करती है; यह कनेक्शन टाइम आउट होना चाहिए।

लूपबैक ट्रैफ़िक raw/PREROUTING से गुज़रता है, इसलिए यह सिद्ध करता है कि नियम वास्तव में पैकेट ड्रॉप करता है और केवल तालिका में मौजूद नहीं है।

सीमाएँ