Linux TCP Use-After-Free: पैच या मिटिगेट?

आपके kernel में TCP handshake path पर एक ऐसा use-after-free है जिसे रिमोट से ट्रिगर किया जा सकता है, आपके distro ने अभी तक fix शिप नहीं किया है, और कोई पहले ही काम करने वाला root exploit दिखा चुका है। तो प्लान क्या है: बस इंतज़ार करें, या firewall पर packets ड्रॉप करना शुरू करें? CVE-2026-98432 के नाम से disclose हुआ यह Linux TCP use-after-free security operations के सबसे पुराने फ़ैसले का साफ़ उदाहरण है: patch करें या mitigate। ईमानदार जवाब यह है कि दोनों विकल्प बराबर नहीं हैं। इनमें से एक असल में समस्या को ठीक करता है।

मैं इस तरह की दोनों तरफ़ की कॉल्स में रह चुका हूँ। एक बार मैंने emergency kernel rollout को इसलिए रोके रखा क्योंकि कागज़ पर mitigation काफ़ी अच्छा लग रहा था। एक बार मैंने एक “temporary” firewall rule को आठ महीने तक production में चुपचाप सड़ते देखा, जबकि सब भूल चुके थे कि वह किस CVE को ढक रहा था। यह bug इस पर बात करने का अच्छा मौका है कि कौन सा तरीका कब जीतता है, क्योंकि यहाँ trade-offs असामान्य रूप से साफ़ हैं।

TCP Use-After-Free असल में क्या है

Mechanics इसलिए मायने रखते हैं क्योंकि वही तय करते हैं कि mitigation क्या कर सकता है और क्या नहीं। जब आपका server IPv4 TCP connection स्वीकार करता है, तो kernel अधूरे handshake को एक हल्के request socket में ट्रैक करता है, और handshake पूरा होने पर उसे पूरे socket में बदल देता है। अगर peer के IPv4 header में options थे, तो kernel उन्हें अपने replies में echo करने के लिए सेव कर लेता है। Bug यह है: kernel ने वे saved options बिना copy किए नए connection को थमा दिए, और फिर उन्हें तुरंत free कर दिया, जबकि दूसरा CPU अभी भी उन्हें पढ़कर handshake reply बना रहा हो सकता है। यह एक use-after-free है, जो एक रिमोट और बिना authentication वाले peer से पहुँच सकता है, और वह भी आपकी application का एक भी line चलने से पहले।

Upstream fix, Eric Dumazet का, चार लाइन का है: दो सामान्य kfree() calls को kfree_rcu() से बदला गया है, जो तब तक free को टालता है जब तक हर reader memory का इस्तेमाल पूरा न कर ले। इस तरह के bug class के लिए यही canonical kernel fix है। RCU के तहत readers ऐसे references रखते हैं जो आपको दिखते नहीं, इसलिए आप grace period खत्म होने देते हैं और फिर memory वापस लेते हैं। Kernel के अपने CNA ने इसे CVSS 9.8 दिया। Red Hat ने शुरू में 8.1 दिया, फिर 30 अक्टूबर को इसे 9.8 Critical तक बढ़ा दिया, यह कहते हुए कि इसके लिए कोई network prerequisites नहीं चाहिए।

दो बातें exposure का हिसाब बदल देती हैं। पहली, race हल्के तरीके से हारती है: असफल कोशिश सिर्फ़ handshake को फेल करती है और मशीन को panic नहीं कराती, इसलिए attacker अनिश्चित काल तक retry कर सकता है। दूसरी, Anthropic ने जो exploit path दिखाया वह उन hosts को निशाना बनाता है जिन पर multipath TCP listener है। Go Security Team के अनुसार, Go 1.24 से Go programs Linux पर, जहाँ भी kernel इजाज़त दे, डिफ़ॉल्ट रूप से MPTCP listeners खोलते हैं। अपना fleet जाँचें:

ss -Mlnp                 # MPTCP listeners and their owning processes
sysctl net.mptcp.enabled # 1 means apps may open MPTCP sockets

ss -M का खाली output मतलब है कि कोई MPTCP listener नहीं है। पर निश्चिंत मत होइए। Go team साफ़ कहती है कि असली bug MPTCP-specific नहीं है। यह handshake processing में एक generic UAF है, और MPTCP बस वह रास्ता है जिसे किसी ने end-to-end साबित किया है।

Patch का रास्ता: Fixed kernel, reboot, बस हो गया

Patching का वर्णन करना बोरिंग है, क्योंकि यही एकमात्र विकल्प है जो vulnerability को सच में खत्म करता है, उसे सिर्फ़ नए रूप में नहीं ढालता। Fixed kernels 11 और 15 अक्टूबर को हर maintained stable line में upstream पर आ गए, और यह bug Linux 4.4 तक पीछे जाता है। यानी बहुत से long-tail systems प्रभावित हैं, जिनमें वे पुराने kernels भी शामिल हैं जिन्हें upstream अब छूता ही नहीं।

पेच का असली जाल reboot है। Kernel update तब तक कुछ नहीं करता जब तक मशीन नए kernel पर boot न हो, और reboot में असली operational cost छिपी है: drain किए गए Kubernetes nodes, failover rehearsals, और वह database primary जिसे कोई कारोबारी घंटों में हिलाना नहीं चाहता। इसीलिए “बस patch कर दो” सलाह हमेशा सही होती है, पर पर्याप्त कभी नहीं। आपको rollout plan चाहिए: पहले canary hosts, फिर stateless tiers, फिर maintenance windows के साथ stateful वाले। अगर आप पहले कभी fleet-wide emergency kernel rotation से गुज़रे हैं, तो तरीका आप जानते हैं। जो टीमें इसे अच्छे से संभालती हैं, वे वही हैं जिन्होंने आग न लगी हो तब भी node draining का अभ्यास किया। शांत मंगलवार को बनाई defensive engineering habits ही 9.8 के दौरान काम आती हैं।

एक जाल जिसका नाम लेना ज़रूरी है: dpkg -l या rpm -q kernel में fixed package दिखना कुछ नहीं बताता, अगर चल रहा kernel उससे पुराना है। uname -r बताता है कि असल में क्या चल रहा है। RHEL-like systems पर needs-restarting -r साफ़ बता देगा कि reboot बाकी है या नहीं। मैंने ऐसे post-incident reports देखे हैं जहाँ “patched” fleet असल में installed-but-not-running kernels का fleet थी। Running version को upstream नंबर से नहीं, अपने distro के tracker से मिलाएँ, क्योंकि distro kernels अपने versioning के तहत backports रखते हैं।

Mitigation का रास्ता: IPv4 options drop करें, MPTCP बंद करें

प्रकाशित अंतरिम mitigation एक nftables rule है जो आने वाले IPv4 TCP packets को, जिनमें IP options हों, drop करता है। यही vulnerable path का trigger है। अगर आप MPTCP इस्तेमाल नहीं करते, तो sysctl -w net.mptcp.enabled=0 से इसे बंद करके इसे और मज़बूत कर सकते हैं। दोनों तेज़ हैं, reboot नहीं चाहिए, और configuration management के ज़रिए एक दोपहर में deploy हो सकते हैं। यही इनका आकर्षण है।

अब वह हिस्सा जो आपके उत्साह को थोड़ा संयमित करना चाहिए: Red Hat का अपना bulletin कहता है कि उसका rule “इस vulnerability का exposure कम करता है, पर इसे पूरी तरह रोक नहीं सकता।” यह वाक्य दो बार पढ़िए। Mitigation attack surface को संकरा करता है, उसे बंद नहीं करता। IP options वाले packets सामान्य traffic में दुर्लभ हैं। ज़्यादातर middleboxes वैसे भी उन्हें drop कर देते हैं, और इसी वजह से खुले internet पर exploitation को लगभग असंभव माना जाता है। पर “दुर्लभ” और “असंभव” अलग शब्द हैं, और यह bug generic handshake code में है, सिर्फ़ उस options path में नहीं जिसे किसी ने टेस्ट किया।

इसकी एक सूक्ष्म कीमत भी है: mitigations बंद होने का झूठा एहसास देते हैं। Ticket “लगभग हो गया” में चला जाता है, patching की urgency खत्म हो जाती है, और छह हफ़्ते बाद आप अब भी एक packet filter के पीछे vulnerable kernel चला रहे होते हैं, और यह याद धुंधली पड़ चुकी होती है कि ऐसा क्यों किया गया था। इस पैटर्न पर मैंने पहले PHP के critical CVE window के संदर्भ में लिखा है, जहाँ वे टीमें बेहतर रहीं जिन्होंने vulnerable चीज़ को सीधे offline कर दिया, न कि जिन्होंने चालाक filters की परतें चढ़ाईं। सबक वही है, stack अलग है।

Patch बनाम Mitigate: कौन सा कब जीतता है

यहाँ मेरा ईमानदार scorecard है, जो दबाव में यह फ़ैसला करने के कई सालों के बाद बना है।

• आपके distro के लिए fixed kernel उपलब्ध है। Patch सीधे जीतता है। Debian, SUSE Enterprise, Oracle UEK और Amazon Linux, सबने fixes शिप कर दिए हैं। चार लाइन के upstream fix से बेहतर कोई mitigation नहीं है। Reboots शेड्यूल करें, rings में roll करें, आगे बढ़ें।
• अभी तक fixed kernel नहीं है, और exposure असली है। तुरंत mitigate करें, क्योंकि mitigations इसी के लिए होते हैं। Ubuntu और RHEL अक्टूबर के आखिर तक भी “Vulnerable”/“affected” थे। अगर आप internet-facing हैं और MPTCP listener है, तो आज ही IP-options वाले packets drop करें और MPTCP बंद करें, साथ ही fixed kernel को उसी तरह ट्रैक करें जैसे किसी blocking release को करते हैं।
• Internet-facing, पर managed front door के पीछे। आपकी urgency घटती है। AWS का मार्गदर्शन कि traffic उनके load balancers, CloudFront या API Gateway से होकर आता है, इसलिए वह raw untrusted TCP की तरह आपके instances तक नहीं पहुँचता, ठीक है। फिर भी mitigate करें (यह सस्ता है), और patch एक सामान्य cycle में करें, emergency cycle में नहीं।
• Single-core या single-queue systems। कम प्राथमिकता। Race के लिए कई CPUs पर एक साथ packet processing चाहिए। Embedded और छोटी VMs को कुछ राहत मिलती है, पर ये अक्सर वही मशीनें होती हैं जिन्हें कोई कभी reboot नहीं करता, तो “कम प्राथमिकता” को “कभी नहीं” मत बनने दें।
• End-of-life kernels (upstream पर 5.10 से पहले)। Mitigation ही एकमात्र upstream-से-स्वतंत्र विकल्प है। यही वह स्थिति है जहाँ mitigations सच में जीतते हैं, क्योंकि विकल्प एक vendor backport है जो शायद कभी न आए। यह एक ज़ोरदार संकेत भी है कि वही बॉक्स स्वयं vulnerability है, और असली fix उसे बदलना है।

असली कहानी distro का अंतर है

जो बात आपको परेशान करनी चाहिए वह bug नहीं है। चार लाइन के UAF fixes stable kernels में हर महीने आते हैं। परेशान करने वाली बात यह है कि दुनिया के दो सबसे बड़े server distributions, Ubuntu और RHEL, upstream के दो हफ़्ते से ज़्यादा बाद भी बिना shipped fixes के थे, जबकि Amazon Linux ने अपने हर kernel को patch कर दिया था और AlmaLinux, एक community rebuild, के पास upstream से पहले testing में fixed kernels थे। HN पर लोगों ने यह देखा और उनकी नाराज़गी जायज़ है, क्योंकि ये वही distributions हैं जो server readiness के नाम पर सबसे ज़्यादा मार्केटिंग करते हैं।

Practitioners के लिए सबक बेरंग है: आपकी exposure window आपके vendor की backport pipeline तय करती है, upstream नहीं। इसके लिए दो बातें बनती हैं। पहली, अपने distro के tracker URLs जानें और उन्हें सच में देखें। यह CVE NVD पर बिना analysis के “Received” पर पड़ा रहा, जबकि kernel CNA, Red Hat और distros सबके पास विस्तृत पन्ने थे। दूसरी, distro की responsiveness को चयन का मानदंड बनाएँ। Amazon Linux ने अभी दिखाया कि उसकी kernel-fix pipeline दोनों incumbents से काफ़ी तेज़ है। यह मार्केटिंग डेक में मायने नहीं रखेगा, पर Halloween weekend पर जब 9.8 गिरता है, तब मायने रखेगा।

AI-लिखा exploit घड़ी बदल देता है

Disclosure की सबसे महत्वपूर्ण पंक्ति आसानी से नज़रअंदाज़ हो जाती है: Anthropic का कहना है कि उसके Claude model ने एक काम करने वाला remote-root exploit बनाया। शुरुआती prompting के बाद, kernel pointer leak से root shell तक मशीन-समय एक घंटे से कम में लगा। उन्होंने इसे प्रकाशित नहीं किया, और HN पर skeptics ने “trust me bro” वाले अंदाज़ पर खूब मज़े लिए। ठीक है। पर मार्केटिंग का हिस्सा घटा भी दें, तो दिशा साफ़ है: “diff stable tree में आया” और “काम करने वाला exploit मौजूद है” के बीच का समय सिकुड़ रहा है, क्योंकि exploit लिखने की रुकावट कभी bug नहीं थी। रुकावट वह इंसान था जो diff पढ़कर heap grooming कर सके।

इससे patch बनाम mitigate का फ़ैसला करने की खिड़की सिकुड़ती है। जब exploit बनाने में हफ़्ते लगते थे, तब “अभी mitigate करें, अगली maintenance window में patch करें” उचित था। जब कोई model सार्वजनिक commit से रातों-रात PoC तैयार कर सके, तो आपका mitigation चरण घंटों में मापा जाना चाहिए, और patch चरण दिनों में। चार लाइन का fix सार्वजनिक है। कोई भी उसे पढ़ सकता है। मान लीजिए कि exploit भी उतना ही आसान है।

मेरी सिफ़ारिश

Patch करें। Mitigate सिर्फ़ एक पुल के रूप में करें, और उस पुल पर एक expiry date लगाएँ। ठोस रूप से: अगर आपके distro के पास fixed kernel है, तो अभी roll करना शुरू करें और हर reboot के बाद uname -r से जाँचें। अगर आप Ubuntu या RHEL पर हैं, तो आज ही IP-options drop और MPTCP बंद करें, फिर गायब kernel fix को blocking dependency मानें। Tracker को हफ़्ते में नहीं, रोज़ देखें। पहले internet-facing और MPTCP listener वाली चीज़ों को प्राथमिकता दें, फिर हर उस चीज़ को जो inbound TCP स्वीकार करती है, यानी लगभग सब कुछ। Containers आपको नहीं बचाते, क्योंकि वे host kernel साझा करते हैं, इसलिए nodes को patch करें।

इस bug का गहरा सबक वही है जो यह हर कुछ सालों में नए CVE नंबर के साथ सिखाता है: mitigations समय खरीदते हैं, पर छेद सिर्फ़ patches बंद करते हैं, और mitigations जितना समय देते हैं, वह लगातार छोटा होता जा रहा है। ज़रूरत पड़ने से पहले तेज़ और सुरक्षित kernel rollouts की क्षमता बनाइए, क्योंकि अगला चार-लाइन fix पहले से किसी की queue में पड़ा है।