netprobe — CVE-2026-98432

नमस्ते। CVE-2026-98432 लिनक्स कर्नेल में दूरस्थ रूप से शोषणीय Use-After-Free है। कुछ रिपोर्टों में कहा गया है कि AI लैब्स ने Multi-Path TCP (MPTCP) के माध्यम से लगभग ~45 मिनट में इसका शोषण किया। यह कमजोरी वास्तव में IPv4 TCP स्टैक में ही है, बात बस यह है कि MPTCP ही एकमात्र दूर-दूर तक व्यावहारिक तरीका है जिससे कमजोर कोड पथ तक पहुँचा जा सकता है। फिर भी, ~45 मिनट को बहुत गहरी जाँच से गुजरना चाहिए।

• कमजोर अंतराल कोड द्वारा लगभग ireq_opt लोड और पहले डीरेफ़रेंस के बीच की दूरी तय करता है।
• फ्री 100 µs से मिलीसेकंड बाद होता है (accept + close)।
• विंडो में इंटरप्ट आना पर्याप्त नहीं है; CPU को फ्री लेटेंसी से अधिक समय तक रीडर से दूर रहना होगा।
• एक सामान्य (!PREEMPT_RT) कर्नेल पर, softirqs बिल्कुल शेड्यूल नहीं होते और hard IRQs की बाढ़ भी लगभग 10ns में पूरी हो जाएगी, यानी use-after-free होने के लिए आवश्यक फ्री से बहुत पहले।
• डुप्लिकेट SYN और ACK एक ही 4-tuple ले जाते हैं, इसलिए RSS/RPS/sk_incoming_cpu उन्हें एक ही रिसीव क्यू में रखते हैं और एक ही CPU पर प्रोसेस करते हैं। दूसरे शब्दों में: एक CPU पर Softirqs क्रमबद्ध होते हैं और फ्लो एफ़िनिटी के कारण, UAF के लिए रेस करने वाला कोई रीडर नहीं बचता।

निश्चित रूप से ऐसे कस्टम लिनक्स कर्नेल हैं जो per-packet steering विकल्पों के साथ MPTCP का उपयोग करते हैं जो संभवतः इस कमजोरी को "सबसे शुद्ध अर्थ में" पहुँच योग्य बनाते हैं। व्यावहारिक रूप से, आप लगभग निश्चित रूप से ऐसा कर्नेल कॉन्फ़िगरेशन नहीं चला रहे हैं, और आप इतने अभागे भी नहीं हैं कि कोई लेटेंसी-करीब-पर्याप्त और उस अंतराल को भरने के लिए पर्याप्त दृढ़ हो।

शोषण को दूर-दूर तक व्यावहारिक बनाने वाला प्राथमिक कारक वर्चुअलाइज़्ड/ओवरसब्सक्राइब्ड VMs हैं, जिनमें PREEMPT_RT, threadirqs, आदि होते हैं... जो कुछ ऐसा है जिस पर हमलावर का कोई नियंत्रण या प्रभाव नहीं होता जब तक कि उनके पास कुछ अतिरिक्त विशेषाधिकार प्राप्त/प्रमाणित पहुँच न हो। उद्योग में मेरे कुछ मित्र हैं जो संभवतः एक-दो तरकीबें जानते हैं जो मेरा मन बदल देंगी, लेकिन मुझे कुछ नहीं पता, AI खाली हाथ रहा, और कम से कम वह "तरकीब" अगर मौजूद है, तो व्यापक रूप से ज्ञात नहीं है।

आपको अपने सर्वर पैच करने चाहिए, लेकिन शायद इससे घबराना नहीं चाहिए। इस रेपो में बाकी सब कुछ, नीचे की पंक्तियों सहित, AI द्वारा उत्पन्न है, लेकिन मैंने सत्र को दिशा दी और सटीकता के लिए आर्टिफैक्ट्स की समीक्षा की है।

निम्नलिखित है:

एक दूरस्थ ब्लैक-बॉक्स प्रोब जो पैकेट-स्तरीय साक्ष्य के साथ CVE-2026-98432 (लिनक्स IPv4 TCP ireq_opt / inet_opt use-after-free) की उपस्थिति प्रदर्शित करता है — कर्नेल संस्करणों के मिलान से नहीं।

यह use-after-free पर रुक जाता है: यह सिद्ध करता है कि कर्नेल ने मुक्त स्मृति पढ़ी और यह वायर पर बताया। यह KASLR को बायपास नहीं करता, नियंत्रण प्रवाह को हाईजैक नहीं करता, या कोड निष्पादित नहीं करता।

केवल अधिकृत परीक्षण। रेस प्रोब लक्ष्य को अस्थिर कर सकता है; क्रैश हुआ कर्नेल एक संभावित परिणाम है। इसका उपयोग केवल उन होस्ट्स पर करें जिनके आप स्वामी हैं या जिनके परीक्षण के लिए आपके पास लिखित अनुमति है।

---

बग क्या है

फिक्स e3f33b0a1d89d738e2b913dab519226eaf76e15b (ipv4: free inet_opt and ireq_opt after an RCU grace period) है, जो inet_sock_destruct() और tcp_v4_reqsk_destructor() में kfree() से kfree_rcu() में दो-पंक्ति का परिवर्तन है।

• tcp_v4_init_req() SYN के प्रतिध्वनित IP विकल्पों (Record Route / Timestamp) को ireq->ireq_opt में संग्रहीत करता है।
• tcp_v4_syn_recv_sock() पॉइंटर को कॉपी करने के बजाय चाइल्ड सॉकेट को स्थानांतरित करता है।
• एक समवर्ती पुनःप्रेषित SYN अभी भी rcu_read_lock() के अंतर्गत ireq->ireq_opt पढ़ता है और इसे ip_options_build() में उपयोग करता है।
• यदि चाइल्ड (या रिक्वेस्ट सॉकेट) पहले मुक्त हो जाता है, तो वह पठन use-after-free है और मुक्त ऑब्जेक्ट की सामग्री SYN-ACK में कॉपी की जाती है।

वह अंतिम बिंदु डिटेक्टर है: कर्नेल बासी विकल्प बाइट्स को प्रेषक को वापस प्रतिध्वनित करता है।

दायरा सुधार: CVE रिकॉर्ड सामान्य IPv4 TCP है। केवल Anthropic का ब्लॉग इसे "multipath TCP listener" से जोड़ता है; किसी भी CVE/NVD/Red Hat/Debian/Ubuntu टेक्स्ट में MPTCP का उल्लेख नहीं है। प्रोब पहले सादे TCP का परीक्षण करता है।

---

साक्ष्य स्थिति

तीन स्वतंत्र चरण, सबसे कमजोर से सबसे मजबूत:

चरण	यह क्या दर्शाता है	आर्टिफ़ैक्ट
स्टैटिक (build-id पिन किया गया)	चल रहे कर्नेल की कोड संरचना: दोनों डिस्ट्रक्टरों पर सादा kfree = असुरक्षित; kvfree_call_rcu = पैच किया गया	verify-local, नीचे तालिका
सिंथेटिक ओरेकल	जब कोई रिस्पॉन्डर पुनःउपयोग किए गए स्लैब मेमोरी को प्रतिध्वनित करता है तो वायर डिटेक्टर सक्रिय होता है	scripts/validate_synthetic.sh → CONFIRMED VULNERABLE
डायनामिक, कर्नेल-स्तरीय (KVM लैब)	KASAN ip_options_build में वास्तविक slab-use-after-free की रिपोर्ट करता है, कमिट के स्टैक के साथ; समान ट्रैफ़िक वाला kfree_rcu कर्नेल स्वच्छ रहता है	evidence/guest-inst-vuln6-KASAN.log, evidence/guest-inst-patched2-CONTROL.log
वायर-दृश्य, वास्तविक कर्नेल (गैर-KASAN लैब)	वायर पर SYN-ACK ने प्रतिध्वनित टाइमस्टैम्प के बजाय स्प्रे किए गए विकल्प ब्लॉक (42 04 be ef…) को ले जाया; kfree_rcu नियंत्रण स्वच्छ रहा	evidence/race-stage1-wire-uaf.json, evidence/race-control-kfree_rcu.json

डायनामिक चरण एक विशेष रूप से निर्मित 7.0.14 गेस्ट है (KASAN + एक बूट-पैरामीटर विंडो स्ट्रेच) जिसमें प्रति-पैकेट CPU स्टीयरिंग है: पुनःप्रेषित SYN को एक vCPU पर प्रोसेस किया जाता है, ACK/ट्रांसफ़र को दूसरे पर, और विक्टिम के accept()+close() को तीसरे पर, ताकि ओवरराइड आकस्मिक के बजाय नियमित हो। कर्नेल ने स्वयं रिपोर्ट किया:

BUG: KASAN: slab-use-after-free in ip_options_build
Read of size 16 ... by task swapper/0 (cpu0, softirq)
  __asan_memcpy <- ip_options_build <- ip_build_and_send_pkt
  <- tcp_v4_send_synack <- tcp_rtx_synack <- tcp_check_req <- tcp_v4_rcv
Freed by task 1 (victim, cpu3):
  kfree <- inet_sock_destruct <- __sk_destruct <- inet_release <- __x64_sys_close
object: kmalloc-96, 16 bytes in (struct ip_options at the rcu_head offset)

प्लस 30 रीडर-साइड READ-AFTER-FREE रिकॉर्ड (फ्री के 71–322 µs बाद पढ़ा गया, optlen=40, KASAN शैडो 0xfb)। पैच किया गया कंट्रोल (kfree_rcu, ऑब्जेक्ट फ़ाइल में सत्यापित) ने वही रेस और होल्ड चलाया: 0 KASAN, 0 read-after-free। यही भेद्यता है, कोई वर्ज़न अनुमान नहीं।

स्वच्छ रिमोट रन पैच क्यों नहीं है

रीडर कोई लंबा लूप नहीं है। tcp_v4_send_synack() ireq->ireq_opt लोड करता है और उसे ip_build_and_send_pkt()/ip_options_build() को पास करता है, जिसका memcpy use-after-free रीड है; लोड और रीड में कुछ ही निर्देशों का अंतर है (दसियों से सैकड़ों नैनोसेकंड)। फ्री साइड — विक्टिम के accept()+close() के बाद चाइल्ड का विनाश — बहुत बाद में होता है: अकेला मापा गया क्लोज़ चक्र 61–92 µs है, और ACK→विनाश विलंबता क्रॉस-CPU वेकअप जोड़ देती है।

इसलिए ये दो घटनाएँ केवल साथ में दुर्लभ नहीं हैं; वे रचना के अनुसार ~90 µs से अलग हैं, और रीड फ्री से बहुत पहले ही समाप्त हो जाता है। प्राकृतिक-टाइमिंग प्रयोग इसे मात्रात्मक रूप से दर्शाता है: उसी इंस्ट्रुमेंटेड कर्नेल के साथ, बिना विंडो स्ट्रेचिंग, ~140k रेस प्रयास और एक समवर्ती हाफ-ओपन चर्न,

stats: frees=180223 overlaps=0 raf=0        KASAN: 0

रीडर की विंडो के अंदर मुफ़्त कभी एक बार भी नहीं उतरा। एक दूसरे, अधिक मज़बूत प्रयास ने लैब के स्लैब स्प्रे का उपयोग किया: 8,000 प्रयास, प्रत्येक में 200 पुनःप्रेषित SYN (1.6M स्वतंत्र रीडर विंडो) एक प्राचीन कर्नेल के विरुद्ध, जिसका रीडर vCPU चलने योग्य रखा गया था और होस्ट CFS हॉग्स द्वारा प्रीम्प्ट किया गया था - फिर भी शून्य SYN-ACK जो स्प्रे ले जाए। रीडर vCPU लगभग हर 5 ms रनटाइम में एक बार प्रीम्प्ट होता है; 20-40 s रनटाइम के विरुद्ध ~10 ns की 2M विंडो एक पूर्ण रूप से एकसमान मॉडल के अंतर्गत भी मुट्ठी भर हिट हैं, और देखा गया शून्य कहता है कि प्रीम्प्शन बिंदु गेस्ट इंस्ट्रक्शन स्ट्रीम में एकसमान नहीं हैं।

इसलिए वायर प्रमाण के लिए रीडर को नियतात्मक रूप से विलंबित करने की आवश्यकता होती है, जो लैब बूट-पैरामीटर विंडो स्ट्रेच (reader_hold_us) के साथ करता है; एक वास्तविक लक्ष्य पर केवल उन ~10 ns के भीतर एक हाइपरवाइज़र या शेड्यूलर स्टॉल ही ऐसा कर सकता है। यही कारण है कि रिमोट प्रोब एक सकारात्मक को प्रमाण मानता है और एक नकारात्मक को एक सीमा, कभी भी "पैच्ड" नहीं।