CVE-2026-43655 AppleM2ScalerCSCDriver use-after-free के लिए सार्वजनिक प्रकटीकरण

विक्टिम कनेक्शन एसिंक्रोनस ऑपरेशन सबमिट करता है और फिर बंद कर दिया जाता है। उसके बाद रिप्लेसमेंट कनेक्शन खोले जाते हैं और अपना मार्कर 0xBEEF0002 सेट करते हैं। जब अगला स्केलर शेड्यूलिंग चक्र चलता है, तो गलती (fault) रिप्लेसमेंट मार्कर (x9 = 0x00000000BEEF0002) देखती है, विक्टिम मार्कर नहीं। यह साबित करता है कि शेड्यूलर ने एक ऑपरेशन स्लॉट से पढ़ा जो मुक्त हो चुका था और फिर एक अलग कनेक्शन को पुन: आवंटित (reallocated) कर दिया गया था।

प्रभावित कॉन्फ़िगरेशन

• देखा गया प्रभावित OS: iOS 26.4
• निम्नलिखित में ठीक किया गया: iOS 26.5 / iPadOS 26.5 / macOS Tahoe 26.5
• Kext: com.apple.driver.AppleM2ScalerCSCDriver
• उपयोगकर्ता-क्लाइंट पथ: IOSurfaceAcceleratorClient
• PoC द्वारा उपयोग किए गए ऐप अधिकार (entitlements): केवल get-task-allow
• कोई जेलब्रेक नहीं, कोई प्लेटफ़ॉर्म अधिकार (platform entitlement) नहीं, कोई विशेष ऐप्पल-प्राइवेट अधिकार नहीं

मूल कारण (Root cause)

AppleM2ScalerCSCDriver स्केलर क्लाइंट के बीच शेड्यूलर स्थिति (scheduler state) साझा रखता है। प्रासंगिक लाइफ़टाइम बेमेल (lifetime mismatch) इस प्रकार है:

1. एक क्लाइंट एसिंक्रोनस स्केलर ऑपरेशन सबमिट करता है।
2. वे ऑपरेशन शेड्यूलर-स्वामित्व वाली स्थिति में डाल दिए जाते हैं।
3. क्लाइंट कनेक्शन IOServiceClose के साथ बंद कर दिया जाता है।
4. प्रति-क्लाइंट ऑपरेशन स्टोरेज मुक्त कर दी जाती है।
5. बंद किए गए क्लाइंट से संबंधित प्रविष्टियों को साझा शेड्यूलर स्थिति से पूरी तरह से हटाया नहीं जाता है।
6. बाद में शेड्यूलर पास पुराने ऑपरेशन पॉइंटर्स (stale operation pointers) को प्रोसेस करता है।

टियरडाउन पथ बंद होने वाले क्लाइंट की लंबित शेड्यूलर प्रविष्टियों को साझा शेड्यूलर हीप (shared scheduler heap) से नहीं हटाता है। शेड्यूलर बाद में उन पुराने पॉइंटर्स के माध्यम से फ़ील्ड पढ़ता और लिखता है।

विश्लेषण के दौरान देखे गए महत्वपूर्ण फ़ील्ड:

ऑपरेशन आवंटक (operation allocator) का व्यवहार बग को देखने योग्य बनाता है: मुक्त ऑपरेशन स्लॉट बाद में विभिन्न कनेक्शनों से ऑपरेशन द्वारा पुन: उपयोग किए जा सकते हैं। एक विक्टिम कनेक्शन को बंद करके और तुरंत नए कनेक्शन स्प्रे करके, PoC पुराने शेड्यूलर प्रविष्टियों को उस मेमोरी की ओर इशारा करने का कारण बन सकता है जो अब स्प्रे कनेक्शनों के स्वामित्व में है।

x9 = 0xBEEF0002 UAF को क्यों साबित करता है

PoC विक्टिम/स्प्रे विभाजन का उपयोग करता है:

1. विक्टिम कनेक्शन मार्कर 0xDEAD0001 सेट करता है।
2. विक्टिम 50 एसिंक्रोनस स्केलर ऑपरेशन सबमिट करता है।
3. विक्टिम कनेक्शन बंद कर दिया जाता है, जिससे विक्टिम ऑपरेशन ऑब्जेक्ट मुक्त हो जाते हैं।
4. स्प्रे कनेक्शन मार्कर 0xBEEF0002 सेट करते हैं।
5. स्प्रे ऑपरेशन मुक्त ऑपरेशन पूल स्लॉट का पुन: उपयोग करते हैं।
6. शेड्यूलर बाद में पुरानी विक्टिम शेड्यूलर प्रविष्टियों को प्रोसेस करता है।

यदि शेड्यूलर अभी भी जीवित विक्टिम-स्वामित्व वाले ऑब्जेक्ट पढ़ रहा होता, तो देखा गया मान 0xDEAD0001 होता। इसके बजाय, पुन: उत्पन्न गलती 0xBEEF0002 देखती है, जो प्रतिस्थापन स्प्रे कनेक्शनों द्वारा लिखा गया मान है। यह मुख्य प्रमाण है कि शेड्यूलर एक पुराने पॉइंटर को मुक्त और पुन: उपयोग की गई कर्नेल मेमोरी में डीरेफरेंस कर रहा है।

यह क्रॉस-कनेक्शन प्रभाव (cross-connection impact) भी दिखाता है: शेड्यूलर प्रविष्टि एक कनेक्शन द्वारा बनाई गई थी, लेकिन बाद में जो मेमोरी उसने छुआ वह दूसरे कनेक्शन के लिए पुनर्चक्रित (recycled) हो चुकी थी। पुन: उत्पन्न रनों में, अंतिम शेड्यूलर गतिविधि मूल PoC प्रक्रिया के बजाय सामान्य SpringBoard/कम्पोज़िटर/UI गतिविधि द्वारा संचालित हो सकती है।

प्रभाव (Impact)

• मुक्त/पुन: उपयोग की गई ऑपरेशन मेमोरी से कर्नेल रीड (read)।
• शेड्यूलर अकाउंटिंग/स्थिति अपडेट के दौरान मुक्त/पुन: उपयोग की गई ऑपरेशन मेमोरी में निश्चित ऑफ़सेट पर कर्नेल राइट (write)।
• क्रॉस-कनेक्शन प्रभाव क्योंकि शेड्यूलर हीप सभी स्केलर उपयोगकर्ताओं के बीच साझा है।
• क्रॉस-प्रोसेस ट्रिगर व्यवहार क्योंकि कोई भी बाद की प्रक्रिया जो स्केलर शेड्यूलिंग को संचालित करती है, पुरानी प्रविष्टि को प्रोसेस होने का कारण बन सकती है।
• पुरानी शेड्यूलर स्थिति मूल PoC ऐप के तत्काल निष्पादन विंडो से बच सकती है और बाद के शेड्यूलर चक्र पर ट्रिगर हो सकती है।

सार्वजनिक Apple सलाहकार (advisory) प्रभाव का वर्णन इस प्रकार करता है: “एक ऐप अप्रत्याशित सिस्टम समाप्ति का कारण बन सकता है या कर्नेल मेमोरी पढ़ सकता है।”

भौतिक-डिवाइस पुनरुत्पादन अनुक्रम (Physical-device reproduction sequence)

महत्वपूर्ण पुनरुत्पादन विवरण: TEARDOWN UAF टैप करने के बाद, डिवाइस तुरंत पैनिक (panic) नहीं करता है। PoC पहले पुरानी शेड्यूलर स्थिति तैयार करता है। बग अगले स्केलर शेड्यूलिंग चक्र पर ट्रिगर होता है, जो व्यवहार में तब होता है जब SpringBoard/कम्पोज़िटर गतिविधि स्केलर को चलाती है। मेरे भौतिक-डिवाइस पुनरुत्पादन में, मैंने PoC द्वारा पुरानी शेड्यूलर स्थिति तैयार करने के बाद डायनामिक आइलैंड (Dynamic Island) पर टैप/इंटरैक्ट करके उस शेड्यूलर चक्र को ट्रिगर किया।

चरण:

1. PoC चलाने से पहले प्रभावित डिवाइस को रीबूट करें।
2. ScalerTeardownUAF.ipa इंस्टॉल और लॉन्च करें।
3. TEARDOWN UAF पर टैप करें।
4. PoC एक विक्टिम AppleM2ScalerCSCDriver कनेक्शन खोलता है।
5. PoC स्रोत/गंतव्य IOSurface ऑब्जेक्ट बनाता है।
6. PoC एक सिंक्रोनस बेसलाइन स्केलर ऑपरेशन सबमिट करता है।
7. PoC विक्टिम कनेक्शन पर सेलेक्टर 10 क्रेडिट/मार्कर डेटा को 0xDEAD0001 पर सेट करता है।
8. PoC विक्टिम कनेक्शन पर 50 एसिंक्रोनस ऑपरेशन सबमिट करता है।
9. PoC विक्टिम कनेक्शन को IOServiceClose के साथ बंद करता है, जिससे विक्टिम-स्वामित्व वाले ऑपरेशन ऑब्जेक्ट मुक्त हो जाते हैं जबकि पुरानी शेड्यूलर प्रविष्टियाँ बनी रहती हैं।
10. PoC 50 स्प्रे कनेक्शन खोलता है।
11. प्रत्येक स्प्रे कनेक्शन सेलेक्टर 10 क्रेडिट/मार्कर डेटा को 0xBEEF0002 पर सेट करता है।
12. PoC मुक्त ऑपरेशन स्लॉट का पुन: उपयोग करने और शेड्यूलर दबाव को सक्रिय रखने के लिए स्प्रे कनेक्शनों पर अतिरिक्त एसिंक्रोनस ऑपरेशन सबमिट करता है।
13. जब ऐप ट्रिगर के लिए संकेत देता है, तो SpringBoard/कम्पोज़िटर गतिविधि का कारण बनने और स्केलर शेड्यूलर को चलाने के लिए डायनामिक आइलैंड पर टैप/इंटरैक्ट करें।
14. जब पुरानी शेड्यूलर प्रविष्टि प्रोसेस होती है, तो डिवाइस पैनिक/रीबूट होता है।
15. रीबूट के बाद, पैनिक रजिस्टर स्थिति में x9 = 0x00000000BEEF0002 होना सत्यापित करें।

अपेक्षित प्रमाण शर्त:

• x9 = 0x00000000BEEF0002 का अर्थ है कि शेड्यूलर ने स्प्रे मार्कर को उस मेमोरी से पढ़ा जो मूल रूप से मुक्त विक्टिम ऑपरेशन की थी।
• 0xBEEF0002 विक्टिम मार्कर नहीं है; यह प्रतिस्थापन कनेक्शन मार्कर है।
• इसलिए देखा गया शेड्यूलर रीड मुक्त करने और पुन: उपयोग के बाद हुआ।

PoC व्यवहार

शामिल सोर्स निम्नलिखित अनुक्रम निष्पादित करता है:

प्रासंगिक सोर्स फ़ाइल है ScalerTeardownUAF.m।

बिल्ड (Build)

रिपॉजिटरी फ़ाइलें

समयरेखा (Timeline)

• AppleM2ScalerCSCDriver व्यवहार का परीक्षण करते समय प्रारंभिक क्रैश (crash) मिला।
• विक्टिम/स्प्रे मार्कर विभेदन के साथ UAF सिद्ध हुआ: विक्टिम 0xDEAD0001, स्प्रे 0xBEEF0002।
• डायनामिक आइलैंड / SpringBoard कम्पोज़िटर गतिविधि के माध्यम से अगले स्केलर शेड्यूलिंग चक्र को ट्रिगर करके भौतिक-डिवाइस पुनरुत्पादन की पुष्टि की गई।
• Apple ने 26.5 रिलीज़ लाइन में समस्या ठीक की और CVE-2026-43655 निर्दिष्ट किया।