lkeld/cve-2026-43499-pocहथियारबद्ध प्रूफ-ऑफ-कॉन्सेप्ट CVE-2026-43499 (GhostLock) के लिए, जो Linux कर्नेल rtmutex बग है जो स्थानीय विशेषाधिकार वृद्धि को सक्षम बनाता है। इसमें प्रति-डिस्ट्रीब्यूशन एक्सप्लॉइट चेन, तकनीकी राइटअप और विश्वसनीयता परीक्षण शामिल हैं।
rtmutex remove_water() प्रॉक्सी पथ बग जो किसी कार्य के pi_blocked_on को उसके स्वयं के पॉप किए गए कर्नेल स्टैक फ्रेम में लटका हुआ छोड़ देता है।
बग वर्ग और मूल शोषण रणनीति का श्रेय nebusec को जाता है (उनका लेख यहाँ)
इस रिपॉजिटरी में सब कुछ मेरा अपना प्रति-वितरण कार्य है:
प्रत्येक कर्नेल परिवार को मौलिक रूप से भिन्न प्रिमिटिव की आवश्यकता होती है और यही इस चीज़ को इतना दिलचस्प बनाता है।
Ghostlock का ट्रिगर पूरी तरह से विशेषाधिकार-रहित है (तीन futex, दो थ्रेड और कोई नेमस्पेस नहीं)। लटकते पॉइंटर को root में बदलने के पीछे की प्रक्रिया वह जगह है जहाँ प्रत्येक डिस्ट्रो अलग होता है, यह फ्रेम ज्यामिति, शमन, और "ज्ञात कर्नेल पते पर नियंत्रित बाइट्स" का क्या अर्थ है — ये सब बदलते हैं। यह रिपॉजिटरी प्रति लक्ष्य परिवार श्रृंखलाएँ एकत्र करेगा।
| लक्ष्य | श्रृंखला | स्टेजिंग | स्थिति |
|---|---|---|---|
RHEL/CentOS 7 — 3.10.0-1160.102.1.el7 | el7/ — physmap-उपनाम पृष्ठ + auxv पेंटर + sched_setscheduler वॉक | नेमस्पेस में root (विशेषाधिकार प्राप्त कंटेनर) | काम कर रहा है, स्वच्छ बूट पर 40/40 तनाव परीक्षण |
RHEL/CentOS 7 — 3.10.0-693.el7 | समान श्रृंखला, मापी गई फ्रेम ज्यामिति | समान | घटक 10/10 सत्यापित; बस तनाव परीक्षण लंबित है |
पूर्ण तकनीकी विश्लेषण, मूल कारण, स्टॉक 6.x-युग श्रृंखला स्थानांतरित क्यों नहीं होती, प्रिमिटिव निष्कर्ष, मैंने इसके बजाय क्या बनाया था, मापी गई फ्रेम ज्यामिति, और विश्वसनीयता से संबंधित डेटा के लिए प्रत्येक उपनिर्देशिका का WRITEUP.md देखें।
जहाँ चीज़ें कठिन हो जाती हैं — वॉक जाली वेटर के ->lock को उस लॉक के विरुद्ध सत्यापित करता है जो उसे मिला था (3.10 पर BUG_ON(w->lock != lock)), इसलिए आपको कर्नेल-पता योग्य मेमोरी में एक ऐसे पते पर नकली संरचनाएँ चाहिए जिसे आप जानते हों। यही वह चीज़ है जो प्रति कर्नेल बहुत भिन्न होती है (6.x-युग CPU प्रवेश क्षेत्र चाल जो nebusec ने उपयोग की, 3.10 पर मौजूद नहीं है, el7 प्रत्यक्ष आधार मानचित्र को यादृच्छिक करता है, आदि)। प्रत्येक लेख अपना स्वयं का उत्तर दस्तावेजित करता है।
बग और ट्रिगर: आपको कोई विशेषाधिकार, कोई उपयोगकर्ता नेमस्पेस, कुछ भी नहीं चाहिए। कोई भी स्थानीय उपयोगकर्ता काम करता है।
प्रत्येक शस्त्रीकरण अपनी स्वयं की स्टेजिंग बताता है अपने लेख में। el7 श्रृंखला नेमस्पेस में root से स्टेज की गई है (व्यवहार में: विशेषाधिकार प्राप्त कंटेनर में कोई भी RCE — इसे MYSQL इंस्टेंस से उसके UDF प्लगइन पथ के माध्यम से सत्यापित किया गया था, जो एक बहुत ही विशिष्ट स्थिति है)। स्टेजिंग के बाद कर्नेल-पक्ष कार्य केवल उपयोग करता है:
/proc/self/pagemap (नेमस्पेस में CAP_SYS_ADMIN)/proc/kcore (el7 पर नेमस्पेस में CAP_SYS_RAWIO)/proc/kallsyms (kptr_restrict=0 या CAP_SYSLOG)उनमें से कोई भी स्वयं भेद्यता नहीं है, यह केवल स्टेजिंग सुविधाएँ हैं जो उन सूचना लीक के लिए खड़ी हैं जिन्हें मुझे अभी बनाना है।
विशेष रूप से el7 पर, एक पूरी तरह से विशेषाधिकार-रहित श्रृंखला संरचनात्मक कारणों से अवरुद्ध है (3.10 BUG_ON, कोई CEA नहीं, कर्नेल के .data में कोई स्थिर नकली-लॉक जोड़ी नहीं, pagemap PFN गेटिंग)
el7 लेख में पूर्ण विश्लेषण और अनुसंधान दिशाएँ हैं, मुख्य रूप से एक हेड पता सूचना-लीक प्रिमिटिव
panic_on_oops=1 होस्ट पर, एक गलत वॉक पैनिक का कारण बनेगा और मृत मशीन का परिणाम देगा, इसलिए परीक्षण करते समय इसे अपने खतरे मॉडल के हिस्से के रूप में एक सेटिंग मानेंel7/
WRITEUP.md el7 श्रृंखला के लिए पूर्ण तकनीकी लेख
ghostlock_el7.c दोनों परीक्षण किए गए कर्नेल के लिए एकल फ़ाइल PoC
3bfdc63936dd ("rtmutex: remove_waiter() में current के बजाय waiter::task का उपयोग करें"); NPD अनुवर्ती 40a25d59e85b