Bad Epoll: Mythos द्वारा चूका गया बग

Google kernelCTF पर एक गैर-विशेषाधिकार प्राप्त प्रक्रिया का root बनना।

Bad Epoll (CVE-2026-46242) लिनक्स कर्नेल के epoll सबसिस्टम में एक race-condition use-after-free है। यह बग किसी गैर-विशेषाधिकार प्राप्त प्रक्रिया को root बनने देता है, न केवल लिनक्स डेस्कटॉप और सर्वर पर बल्कि Android डिवाइस पर भी।

Bad Epoll को Jaeyoung Chung द्वारा Google kernelCTF को 0-day सबमिशन के रूप में रिपोर्ट और एक्सप्लॉइट किया गया था, जो लिनक्स कर्नेल एक्सप्लॉइट के लिए $71,337+ का पुरस्कार देता है।

[!NOTE] Anthropic के AI, Mythos, ने उसी epoll कोड में एक और race bug खोजा था, लेकिन Bad Epoll को चूक गया।

---

यह गंभीर क्यों है

1. एक दुर्लभ बग जो Android को root कर सकता है। अधिकांश लिनक्स privilege-escalation बग Android को root नहीं कर सकते। Copy Fail और इसके वेरिएंट को, उदाहरण के लिए, ऐसे मॉड्यूल चाहिए जिन्हें Android कभी लोड नहीं करता। Google के kernelCTF पर एक्सप्लॉइट किए गए लगभग 130 कमजोरियों में से केवल लगभग दस ही Android को root करने के उम्मीदवार हैं। Bad Epoll उनमें से एक है।

   • Bad Epoll को Chrome के renderer सैंडबॉक्स के अंदर से भी ट्रिगर किया जा सकता है, जो लगभग हर दूसरे कर्नेल बग को ब्लॉक कर देता है। इसलिए एक renderer एक्सप्लॉइट Bad Epoll के साथ जुड़कर kernel code execution प्राप्त कर सकता है, वही प्रभाव जो Project Zero ने "From Chrome renderer code exec to kernel with MSG_OOB" में प्रदर्शित किया था।

2. कोई kill-switch नहीं। Copy Fail और इसके वेरिएंट को उनके कमजोर मॉड्यूल को अनलोड करके बेअसर किया जा सकता है, लेकिन epoll के पास ऐसा कोई विकल्प नहीं है। यह एक मुख्य कर्नेल सुविधा है जिस पर ऑपरेटिंग सिस्टम, नेटवर्क सेवाएँ और ब्राउज़र सभी निर्भर करते हैं। इसे ठीक करने का एकमात्र तरीका पैच लगाना है।

3. बहुत छोटी race window, लेकिन हमला 99% विश्वसनीय है। बग की race window केवल लगभग छह निर्देशों (instructions) चौड़ी है, और एक सामान्य प्रयास लगभग कभी भी इसे हिट नहीं करता। एक्सप्लॉइट उस window को चौड़ा करता है और एक retry लूप चलाता है जो कर्नेल को कभी क्रैश नहीं करता। परिणाम 99% विश्वसनीय एक्सप्लॉइट है, जैसा कि नीचे हमले का अवलोकन वर्णन करता है।

---

वह बग जिसे Mythos चूक गया

2023 में एक ही commit ने epoll कोड में दो अलग-अलग race conditions पेश कीं, कुल मिलाकर केवल लगभग 2,500 लाइनें। दोनों गंभीर बग निकले जो privilege escalation का कारण बन सकते हैं।

पहला बग Anthropic के Mythos ने खोजा था और इसे CVE-2026-43074 के रूप में रिपोर्ट किया गया। यह परिणाम अपने आप में प्रभावशाली है, क्योंकि कर्नेल race bugs को ढूँढना कठिन माना जाता है। इसने frontier AI मॉडल की race bugs खोजने की क्षमता दिखाई। एक स्वतंत्र शोधकर्ता ने बाद में इसके लिए kernelCTF में 1-day एक्सप्लॉइट सबमिट किया।

दूसरी race Bad Epoll है, जिसे Mythos चूक गया। चूँकि Mythos ने इस छोटे epoll कोड पथ में पहला बग खोजा था, इसलिए संभावना है कि उसने उसी क्षेत्र की गहराई से जाँच की होगी। हम ठीक-ठीक नहीं जान सकते कि वह Bad Epoll को क्यों चूक गया, लेकिन दो कारकों ने इसे खोजना कठिन बनाया होगा।

• Race window बहुत छोटी है। यह केवल लगभग छह निर्देशों चौड़ी है, इसलिए कमजोर कोड को देखते हुए भी सटीक thread interleaving की कल्पना करना कठिन है।

• रनटाइम सबूत बहुत कम थे। CVE-2026-43074 ठीक होने के बाद, Bad Epoll का use-after-free आमतौर पर KASAN को ट्रिगर नहीं करता, जो कर्नेल का मुख्य memory-error डिटेक्टर है। उस सिग्नल के बिना, Mythos के पास इसे वास्तविक बग के रूप में रिपोर्ट करने का पर्याप्त विश्वास नहीं रहा होगा।

Bad Epoll को ठीक करना भी कठिन था। अनुरक्षकों (maintainers) का पहला पैच समस्या को पूरी तरह ठीक नहीं कर पाया, और सही पैच बग की पहली रिपोर्ट के केवल दो महीने बाद आया। यह उस कर्नेल के लिए लंबा समय है जो आमतौर पर सुरक्षा मुद्दों को तत्परता से निपटाता है।

कुल मिलाकर, Bad Epoll दिखाता है कि race conditions हर चरण में कितनी कठिन हैं। इन्हें frontier मॉडल के लिए भी खोजना कठिन है, सही ढंग से ठीक करना कठिन है, और जैसा कि अगला भाग दिखाता है, विश्वसनीय रूप से एक्सप्लॉइट करना भी कठिन है। यह एक vulnerability research दिशा का भी सुझाव देता है जो frontier AI मॉडल की उपस्थिति में खोजे जाने योग्य बनी हुई है: संकीर्ण timing स्थितियों और कमजोर सबूतों के पीछे वास्तविक सुरक्षा प्रभाव को उजागर करना।

---

हमला कैसे काम करता है

जिज्ञासुओं के लिए, यहाँ हमले का एक उच्च-स्तरीय अवलोकन है।

दो जुड़ी हुई epoll वस्तुएँ। दोनों को एक साथ बंद करने से race ट्रिगर होती है।

epoll के दो close पथ एक ही समय में चलते हैं और टकराते हैं। एक वस्तु को मुक्त (free) करता है जबकि दूसरा अभी भी उसमें लिख रहा होता है, और यही use-after-free (UAF) है।

Race window, और एक्सप्लॉइट इसे कैसे चलाता है।

एक्सप्लॉइट चार epoll वस्तुओं का उपयोग करता है जिन्हें दो जोड़ियों में बाँटा गया है। एक जोड़ी race को ट्रिगर करती है, जबकि दूसरी victim बनती है। वहाँ से, एक्सप्लॉइट 8-बाइट UAF write को file ऑब्जेक्ट पर UAF में बदल देता है, और file की सामग्री पर पूर्ण नियंत्रण पाने के लिए cross-cache हमले का उपयोग करता है।

बग को /proc/self/fdinfo के माध्यम से arbitrary kernel memory read में बदलना।

उस नियंत्रण के साथ, एक्सप्लॉइट /proc/self/fdinfo के माध्यम से kernel memory का arbitrary read प्राप्त करता है। अंत में, यह control flow को हाईजैक करता है और root shell पाने के लिए ROP chain निष्पादित करता है।

अधिक विवरण पूरे एक्सप्लॉइट के writeup और code में उपलब्ध हैं।

---

शमन

चूँकि epoll को अक्षम नहीं किया जा सकता, Bad Epoll का कोई सरल workaround नहीं है। एकमात्र उपाय पैच लगाना है।

• अपस्ट्रीम commit a6dc643c6931, या उपलब्ध होते ही अपने distribution का backport लगाएँ।

प्रभावित संस्करण

Bad Epoll को 58c9b016e128 (2023-04-08) द्वारा पेश किया गया था और a6dc643c6931 (2026-04-24) द्वारा ठीक किया गया।