ملخص فشل استغلال GhostLock على PD2229 (SM8475, 5.10.233 GKI)
一、حقائق الثغرة والجهاز
1.1 المعلومات الأساسية لـ CVE-2026-43499 (GhostLock)
| العنصر | القيمة |
|---|
| نوع الثغرة | Use-After-Free على المكدس في مسار rt_mutex / futex PI |
| إصدار الإدخال | Linux 2.6.39-rc1 (مايو 2011، commit 8161239a8bcc) |
| إصدار الإصلاح | الرئيسي 7.1 (commit 3bfdc63936dd)، الفروع المستقرة: 6.1.175 / 6.6.140 / 6.12.86 / 6.18.27 / 7.0.4 |
| الشرط المسبق | CONFIG_FUTEX_PI=y (مفعل افتراضيًا في النوى الرئيسية) |
| CVSS | 7.8 عالية |
| استقرار الاستغلال | سلسلة NebuSec الأصلية 97%، الحصول على صلاحيات root خلال ~5 ثوانٍ |
| جائزة kernelCTF | $92,337 دولار أمريكي |
نطاق النوى المتأثرة:
- 2.6.39 ≤ Linux < 6.1.175 ✅ متأثر
- 6.2 ≤ Linux < 6.6.140 ✅ متأثر
- 6.7 ≤ Linux < 6.12.86 ✅ متأثر
- 6.13 ≤ Linux < 6.18.27 ✅ متأثر
- 6.19 ≤ Linux < 7.0.4 ✅ متأثر
- Android GKI 5.10 غير مشمول في أي فرع إصلاح ← إصدار 5.10.233 على PD2229 متأثر نظريًا
1.2 القياسات الفعلية لجهاز PD2229
二、سلسلة الاستغلال المثالية مقابل التقدم الفعلي على PD2229
2.1 السلسلة الأصلية لـ NebuSec (نجحت على x86_64 / Pixel 10)
1. تجاوز KASLR ← توقيت prefetch / PR_SET_MM_MAP auxv
2. تشغيل UAF ← طريق مسدود يعتمد على PI بثلاثة خيوط ← FUTEX_CMP_REQUEUE_PI يُرجع -EDEADLK
3. استعادة المكدس ← PR_SET_MM_MAP ينسخ auxv إلى إطار مكدس waiter
4. كتابة مقيدة بـ rb_erase ← الكتابة فوق inet6_protos[IPPROTO_UDP]
5. CEA + ROP ← اختطاف تدفق التحكم
6. قلب core_pattern ← قشرة root (نسبة نجاح 97%)
2.2 التقدم الفعلي لكل مرحلة على PD2229
三、نتائج الاستنفاد الشامل لبدائية استعادة المكدس (قياسات PD2229 الفعلية)
3.1 الحسابات الرئيسية لتخطيط إطار المكدس
العمق الإجمالي لمسار futex:
__arm64_sys_futex 0x90
+ do_futex 0xc0
+ futex_wait_requeue_pi 0x1b0
= 0x300
موقع waiter = SYS_SP - 0x300 + 0x20 = SYS_SP - 0x2e0
مسار pselect:
إطار مكدس core_sys_select 0x1c0، stack_fds عند sp+0x50
نطاق التغطية: يبدأ من SYS_SP - 0x1c0 + 0x50 = SYS_SP - 0x170
الفرق مع waiter (SYS_SP - 0x2e0) هو 0x170 (368 بايت) ← لا تداخل
3.2 الطرق الـ 17 المجربة للكتابة على المكدس
فشل 17/17 بالكامل.
3.3 السبب الجذري للفشل
تخطيط المكدس الناتج عن مترجم SM8475 5.10 GKI على PD2229 (PGO + LTO + BOLT) يؤدي إلى عدم تداخل معماري بين stack_fds في core_sys_select وrt_mutex_waiter في futex_wait_requeue_pi. هذه حقيقة موضوعية يحددها المترجم، وليست مشكلة في تقنية الاستغلال.
يذكر مستودع JoinChang بوضوح: "The pselect stack overlay only works when the freed rt_mutex_waiter lands within the user-controllable region of the stack_fds buffer" — PD2229 لا يستوفي هذا الشرط.
四、تحليل مقارن للمستودعات المرجعية العامة
NebuSec/CyberMeowfia — إطار الاستغلال الأصلي
- المستودع: https://github.com/NebuSec/CyberMeowfia
- الهدف: x86_64 Linux / Pixel 10 (6.x GKI)
- استعادة المكدس:
PR_SET_MM_MAP ينسخ auxv إلى مكدس النواة
- نسبة النجاح: 97%، قشرة [root] خلال ~5 ثوانٍ
- قابلية التطبيق على PD2229: ❌
PR_SET_MM_MAP معترض بـ EPERM على Android
JoinChang/ghostlock-oneplus — كسر قفل BL لـ OnePlus
- المستودع: https://github.com/JoinChang/ghostlock-oneplus
- الأجهزة المُتحقق منها:
- OnePlus Ace 6T (PLR110, SM8845) — 6.12.38 GKI ✅
- OnePlus 15 (PLK110, SM8845) — 6.12.23 GKI ✅
- النقاط التقنية:
- استخراج تلقائي للإزاحات: kallsyms (28) + BTF (57) + مشتقة (9) + ثوابت (12) = 103/103
- تغطية مكدس pselect، فرق SP = -64
PSELECT_SHIFT = -2
- سلسلة الاستغلال: futex UAF ← تزييف waiter ← pselect يتحكم بالمكدس ← كتابة مقيدة بـ rb_erase ← selinux_state.enforcing=0 ← الكتابة فوق cred إلى init_cred
- إعلان صريح بعدم الجدوى: "Not Feasible (stack layout incompatible)" — ينطبق فقط على النوى التي يتداخل فيها pselect stack_fds مع waiter
- قابلية التطبيق على PD2229: ❌ عدم تطابق جيل النواة (6.12 مقابل 5.10)، وعدم تداخل تخطيط المكدس
p2p3p/GhostLock-for-OnePlus — استغلال كامل لـ OnePlus 6.12
YuKongA/ghostlock-oplus — OPPO Find N5/X8
تكييف OPPO Find X6 Pro (PGEM10) — 5.15.149
- الجهاز: SM8550, 5.15.149-android13, Android 15
- التقدم: ✅ تجاوز KASLR (perf_event_open + أخذ عينات callchain)؛ المراحل اللاحقة لم تُنشر كاستغلال كامل
- الأهمية: يثبت أن تجاوز KASLR ممكن على 5.15 GKI، لكن مرحلة استعادة المكدس لم تُتحقق علنًا
pubglite55/oppo-ghostlock — OPPO Find N2
- المستودع: https://github.com/pubglite55/oppo-ghostlock
- الجهاز: OPPO Find N2 (CPH2413, SM8475)
- النواة: 5.10.236-android12-9-o-g74d132f4467a
- Android: 16 (BP2A.250605.015)
- تم التنفيذ:
- ✅ Firefox CVE-2026-10702 AAW (المرحلة 1)
- ✅ تجاوز KASLR (حساب مباشر لـ kaslr_base)
- ✅ تشغيل GhostLock FUTEX (FUTEX_CMP_REQUEUE_PI ret=0)
- ✅ تسريب KernelSnitch mm_struct
- ✅ حقن sk_buff في الكومة (نجاح إرسال 4/4)
- ✅ التحقق من 70+ إزاحة عبر IDA Pro
- الانسداد الأساسي:
"pselect غير قادر على التلاعب ببنية waiter — عندما NFDS >336 يكون fd_set على الكومة؛ configfs/ashmem غير مدعومين (اسم SET_NAME لـ ashmem مبتور)؛ جميع مسارات الكتابة الأخرى على النواة مسدودة (/proc/self/mem, /dev/mem, binder)"
- العلاقة مع PD2229: نفس المنصة ونفس الجيل (SM8475، 5.10.236 مقابل 5.10.233)، بفارق 3 إصدارات ثانوية فقط، تواجه نفس القيود المعمارية تمامًا
harry1080/oppo-ghostlock — OPPO Find N2
- المستودع: https://github.com/harry1080/oppo-ghostlock
- الجهاز: OPPO Find N2 (CPH2413, SM8475)
- النواة: 5.10.236-android12-9-o-g74d132f4467a
- Android: 16 (BP2A.250605.015)
- البيان العام للمجتمع:
"pixel10 能利用的版本的 pselect stack_fds 正好和 rt_waiter 在内核栈上重合، هذا الجزء هو في الواقع الأكثر إزعاجًا، في نواة OPPO findN2 لا يتداخل إطارا المكدس لهذين الاستدعاءين إطلاقًا، أو حتى لو تداخلا فهو غير قابل للتحكم، يجب إيجاد طريقة أخرى للتحكم في المكدس، واستخدام استدعاءات نظام أخرى ذات مكدس نواة قابل للتحكم لبناء المكدس، التكييف البسيط للإزاحات مستحيل النجاح، rt_waiter في oppo لا يتداخل إطلاقًا مع pselect stack_fds"
- العلاقة مع PD2229: كلاهما SM8475 5.10 GKI، الاستنتاج قابل للتطبيق بالكامل
4.3 الجدول الإجمالي لمقارنة المستودعات المرجعية
五、رموز وإزاحات النواة الرئيسية (قياسات vmlinux الفعلية لـ PD2229)
العنوان الأساسي الثابت 0xffffffc008000000، يجب إضافة انزلاق KASLR في وقت التشغيل.
بنية rt_mutex_waiter (تخصيص vivo 5.10.233)
struct rt_mutex_waiter {
uint64_t private; // +0x00 (حقل خاص بـ vivo)
struct rb_node {
uint64_t rb_parent_color; // +0x08
uint64_t rb_right; // +0x10 (vivo يبدل الترتيب)
uint64_t rb_left; // +0x18
} tree;
struct task_struct *task; // +0x20
struct rt_mutex *lock; // +0x28
};
// الحجم الإجمالي 0x30 (48 بايت)
六、ما تم تنفيذه مقابل ما يجب تنفيذه
✅ البنية التحتية المنفذة
- تجاوز KASLR —
perf_event_open + أخذ عينات callchain (بنفس طريقة OPPO Find X6 Pro 5.15.149)
- تشغيل UAF — طريق مسدود PI بثلاثة خيوط، FUTEX_CMP_REQUEUE_PI يُرجع -EDEADLK
- جدول رموز كامل — التحقق من 103+ رمزًا عبر IDA (بمنهجية استخراج 103/103 الخاصة بـ JoinChang)
- تخطيط بنية rt_mutex_waiter — تأكيد إزاحات تخصيص vivo
- تحليل دقيق لتخطيط إطار المكدس — اكتمل حساب أعماق مسارات futex و pselect/io_uring
- الاستبعاد الشامل لـ 17 مرشحًا لاستعادة المكدس — إنشاء مصفوفة "غير ممكن" كاملة
❌ غير منفذ (الانسداد الأساسي)
- بدائية استعادة المكدس — تخطيط مكدس مترجم SM8475 5.10 GKI يجعلها غير قابلة للاستخدام معماريًا
- بدائية الكتابة المقيدة — لا يمكن تشغيل rb_erase بسبب فشل استعادة المكدس
- جميع المراحل اللاحقة — انسداد متسلسل
七、الاستنتاج النهائي
⚠️ GhostLock (CVE-2026-43499) غير قابل للاستغلال على PD2229 (vivo X Fold+, SM8475, 5.10.233 GKI, Android 15 OriginOS 5).
السبب الجذري هو تخطيط المكدس الناتج عن مترجم SM8475 5.10 GKI (PGO+LTO+BOLT)، مما يؤدي إلى عدم تداخل معماري بين إطارات مكدس جميع استدعاءات النظام المعروفة وrt_mutex_waiter. هذه حقيقة موضوعية يحددها المترجم، وليست مشكلة في تقنية الاستغلال.
جميع حالات الاستغلال الناجحة كانت على 6.6/6.12 GKI، لأن مخرجات المترجم لهذه النوى الأحدث تجعل pselect fd_set يتداخل تمامًا مع waiter (فرق SP=-64). 5.10 GKI لا يمتلك هذا الشرط.
البنية التحتية المُنشأة
- ✅ بدائية تجاوز KASLR (قناة جانبية perf_event_open)
- ✅ 103+ رمز نواة وإزاحة
- ✅ تخطيط بنية rt_mutex_waiter
- ✅ القدرة على تشغيل UAF
- ✅ مصفوفة استبعاد 17 مرشحًا لاستعادة المكدس
九、فهرس المستودعات المرجعية