pmg110-root

CVE-2026-43499 (futex PI rt_mutex_waiter use-after-free) स्थानीय विशेषाधिकार वृद्धि (local privilege escalation), OPPO PMG110 / K15 Pro+ — MediaTek MT6991, ColorOS 16 के लिए पोर्ट किया गया।

केवल एक फ़ाइल पुश होती है, LD_PRELOAD के माध्यम से चलाएँ:

adb push out/preload-pmg110-16.0.9.400.so /data/local/tmp/preload.so
adb shell chmod 644 /data/local/tmp/preload.so
adb shell LD_PRELOAD=/data/local/tmp/preload.so /system/bin/true

सफलता पर एक स्थायी su पीछे छोड़ दिया जाता है:

adb shell /data/local/tmp/su -c id      # uid=0(root)

डिवाइस पर सत्यापित (2026-07-27): बिना किसी पर्यावरण ओवरराइड के एक सामान्य रन से लगभग 35 सेकंड में uid=0, और उसके बाद एक साधारण अनविशेषाधिकारित adb shell से su उत्तर देता है:

$ adb shell "/data/local/tmp/su -c 'echo 0 > /proc/sys/kernel/kptr_restrict'"
$ adb shell "/data/local/tmp/su -c 'grep -w init_task /proc/kallsyms'"
ffffffe89033e780 D init_task

एक्सप्लॉइट और su इंस्टॉलेशन दोनों इसी डिवाइस पर सत्यापित हैं। उस रूटेड शेल ने जो वापस पढ़ा, वह एक्सप्लॉइट से स्वतंत्र रूप से P0_KERNEL_PHYS_LOAD, प्रतीक ऑफ़सेट और KS_MTE_TAGGED=0 की भी पुष्टि करता है — देखें targets/pmg110-16.0.9.400/NOTES.md।

यह क्या करता है, और क्या नहीं करता

यह Write 1 (SELinux permissive) और Write 2 (cred → init_cred) चलाता है, एक चाइल्ड प्रोसेस को uid=0 पर ले जाता है, और वहाँ से एम्बेडेड su डेमॉन इंस्टॉल करता है।

• अभी भी एक ही फ़ाइल पुश होती है। su कोई दूसरा आर्टिफैक्ट नहीं है: su_daemon.c को एक स्टैंडअलोन aarch64 PIE के रूप में बनाया जाता है और लाइब्रेरी के .rodata में .incbin किया जाता है, इसलिए यह preload.so के अंदर ही समाहित रहता है और रन टाइम पर वापस लिखा जाता है। warhol-root का मार्ग, अपरिवर्तित।
• कोई रूट स्क्रिप्ट नहीं, कोई ksud नहीं, कोई KernelSU नहीं
• कॉल करने वाली प्रोसेस अनविशेषाधिकारित रहती है — यह डेमॉन से पूछकर रूट प्राप्त करती है, जो वही चीज़ है जो आप बाद में शेल से करेंगे
• SELinux को permissive छोड़ दिया जाता है, जैसा warhol-root छोड़ता है: डेमॉन को अपने सॉकेट पर अनविशेषाधिकारित क्लाइंट्स को सेवा देनी होती है। enforcing बहाल करने के लिए रिबूट करें।

su तीन स्थानों पर इंस्टॉल होता है, क्योंकि उनमें से एक वही है जहाँ आप वास्तव में पहुँचेंगे:

डेमॉन /data/local/tmp/temp_su.sock पर सुनता है और /data/local/tmp/su_daemon.log में लॉग करता है। रूट रिबूट के बाद स्थायी नहीं रहता — प्रत्येक बूट के बाद LD_PRELOAD लाइन दोबारा चलाएँ।

KernelSU इंस्टॉलेशन के लिए, इसके बजाय ghostlock-oneplus में /data/local/tmp/a/e मार्ग का उपयोग करें।

warhol-root से संबंध

एक्सप्लॉइट कोर को छोड़कर बाकी सब warhol-root का है, दोबारा आविष्कार करने के बजाय लिया गया:

• लेआउट — targets/<device>/ के नीचे प्रति-डिवाइस हेडर, बिल्ड समय पर source/src/ में स्टेज होते हैं, ताकि DEVICE स्विच करने पर पिछले डिवाइस के हेडर कभी पीछे न छूटें
• बिल्ड — source/Makefile का टूलचेन चयन (NDK यदि उपलब्ध हो, अन्यथा NDK sysroot के विरुद्ध होस्ट clang) और दो-चरणीय एम्बेड नियम जो .so को लिंक करने से पहले build/embed/su_daemon_aarch64_pie उत्पन्न करता है
• su मार्ग — su_daemon.c और su_blob.S warhol-root के साथ बाइट-समान हैं, और su_install.c इसका preload.c इंस्टॉलर है

एक्सप्लॉइट कोर warhol-root का नहीं है। warhol-root popsicle है, जो GKI 6.12 / android16 पर पिन है और जिसका generate_target.py किसी अन्य बैनर को अस्वीकार कर देता है। PMG110 6.6 / android15 है, इसलिए यहाँ का कोर ghostlock 6.6 ट्री है — जो स्वयं उसी कोड का वंशज है (kernelsnitch/utils.h और timeutils.h दोनों रिपॉजिटरी में बाइट-समान हैं), आगे विकसित किया गया।

एक्सप्लॉइट की हर पंक्ति — Write 1, Write 2, KernelSnitch, pselect मार्ग — दोनों ट्री में एक ही कोड है।

su इंस्टॉल कहाँ से कॉल किया जाता है

यह एकमात्र संरचनात्मक अंतर है, और यह इस तथ्य से विवश है कि दोनों ट्री अलग-अलग रूपों में रूट प्राप्त करते हैं।

warhol-root स्वयं एक्सप्लॉइट प्रोसेस को रूट करता है और इसलिए install_embedded_su() को सीधे run_direct_root() से कॉल करता है। यहाँ Write 2 एक forked चाइल्ड के cred पॉइंटर को स्वैप करता है और पैरेंट अनविशेषाधिकारित कॉलर बना रहता है, इसलिए child_main() में चाइल्ड ही एकमात्र संदर्भ है जो इंस्टॉल कर सकता है — वहीं यह चलता है।

दोनों ट्री util.c में एक ही weak install_embedded_su() स्टब रखते हैं जो ENOSYS लौटाता है; strong परिभाषा प्रदान करना ही मार्ग को चालू करता है। यह जानने लायक है क्योंकि एक बिल्ड जो किसी तरह su_install.c छोड़ देता है, फिर भी लिंक होता है और चलता है — वह बस su=0/38 रिपोर्ट करता है और कुछ इंस्टॉल नहीं करता।

बिल्ड

make                      # = make preload -> out/preload-<DEVICE>.so
make DEVICE=<name>        # use targets/<name>/
make devices              # list available DEVICE values
make info                 # show the selected target and the resolved toolchain

टूलचेन अपने आप मिल जाता है: पहले ANDROID_NDK_HOME / ANDROID_NDK_ROOT, फिर Linux और macOS के लिए सामान्य NDK इंस्टॉल स्थान, और इन सबके विफल रहने पर, NDK sysroot को लक्षित करने वाला होस्ट clang। ANDROID_NDK_HOME केवल खोज को ओवरराइड करने के लिए सेट करें। make info अपनी चयनित चीज़ प्रिंट करता है।

बिल्ड दो चरणों का है, जो जानने लायक हिस्सा है:

1. su_daemon.c → build/embed/su_daemon_aarch64_pie, एक स्टैंडअलोन aarch64 PIE
2. su_blob.S उस बाइनरी को .rodata में .incbin करता है, और पूरी चीज़ एक ही preload.so में लिंक हो जाती है

इसलिए एम्बेडेड su को बदलने का एकमात्र तरीका make clean और पुनर्निर्माण है — अकेले su_daemon.c को संपादित करना पर्याप्त है, निर्भरता घोषित है, लेकिन ब्लॉब एक बिल्ड आर्टिफैक्ट है और ट्रैक नहीं किया जाता।

targets/<device>/{target.h,device_offsets.h} प्रत्येक बिल्ड पर source/src/ में फिर से स्टेज किए जाते हैं, ताकि किसी अन्य डिवाइस का पुराना हेडर चुपचाप न उठाया जा सके।

out/*.so ट्रैक नहीं किया जाता (warhol-root के समान परंपरा) — क्लोन करें और make चलाएँ।

.so को -fvisibility=hidden के साथ बनाया गया है और यह शून्य प्रतीकों को निर्यात करता है। एक LD_PRELOAD लाइब्रेरी पूरी प्रोसेस के लिए प्रतीक लुकअप जीत लेती है, इसलिए इसके द्वारा निर्यात की गई कोई भी चीज़ होस्ट बाइनरी या libc में समान-नाम वाले प्रतीक को छायांकित कर सकती है। वह फ्लैग केवल C कोडजन को नियंत्रित करता है, इसलिए su_blob.S अपने दो प्रतीकों को हाथ से .hidden चिह्नित करता है — उन पंक्तियों के बिना ब्लॉब सीमाएँ ही एकमात्र चीज़ होतीं जो लाइब्रेरी अब भी निर्यात करती।

पर्यावरण चर

सत्यापित रन पर इनमें से किसी की आवश्यकता नहीं पड़ी।

लॉग पढ़ना

[*] futex_hashsize 2048 (8 possible CPUs)
[*] ks collisions=3/3 baseline=8 threshold=10x (80) accepted=[1244..1597] slowest_rejected=N
[+] child uid = 0
[+] embedded su wrote 15304 bytes to /apex/com.android.virt/bin/su
[+] embedded su daemon ready pid=NNNN socket=/data/local/tmp/temp_su.sock daemon=/apex/com.android.virt/bin/su
[+] embedded su install ok=1 errno=0 daemon=NNNN
[+] su ready: /data/local/tmp/su and /apex/com.android.virt/bin/su
[+] ghostlock preload verdict: EXPLOIT OK

child uid = 0 का अर्थ है एक्सप्लॉइट का सफल होना; इसके बाद की हर चीज़ इंस्टॉल है। दोनों को जानबूझकर अलग-अलग रिपोर्ट किया जाता है, और वर्डिक्ट भी वैसे ही है:

बीच वाला वह अंतर है जो जानने लायक है: यह बताता है कि target.h में ऑफ़सेट इस बिल्ड के लिए सही हैं और समस्या इंस्टॉल में कहीं है, जो डीबग करने के लिए पूरी तरह से अलग चीज़ है। इसके अंदर su=0/38 (ENOSYS) विशेष रूप से इंगित करता है कि weak स्टब ही लिंक हुआ है।

mm_struct leak failed के बाद आने वाला prepare_kernel_page retry N/24 विफलता नहीं है। यह लूप की प्रगति है, और सफल रन भी इसे दिखाता है। जब तक 24 प्रयास समाप्त नहीं होते और prepare_kernel_page timeout प्रकट नहीं होता, तब तक कुछ भी विफल नहीं हुआ है। इसी तरह child uid = 2000 के साथ probing cfi ... expected=9 दस में से एक राउंड चूकना है।

किसी रन का मूल्यांकन काटे गए लॉग से न करें — उस गलती ने यहाँ गलत निदान का एक पूरा दौर खर्च कर दिया।

पूरी तरह विफल रन भी सामान्य है। pselect रेस 100% नहीं है: एक रन इसे पाँच बार हार सकता है और Write 1 failed पर समाप्त हो सकता है, और अगला रन पहले ही प्रयास में ret=9 के साथ जीत लेता है। इस डिवाइस पर देखा गया। ret=4 expected=9 रेस हारने जैसा दिखता है, न कि गलत target.h — एक विफलता ऑफ़सेट दोबारा निकालने का कारण नहीं है। इसे दोबारा चलाएँ।

फ़ाइलें

लाइसेंस

केवल अधिकृत सुरक्षा अनुसंधान और शैक्षिक उद्देश्यों के लिए।