catxiaoshi/cve-2026-43499دراسة جدوى لـ 43499(ghostlock) لـ PD2229B
# ملخص فشل استغلال 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
| العنصر | القيمة |
|---|---|
| SoC | Qualcomm SM8475 (Snapdragon 8 Gen 1 Plus) |
| إصدار النواة | 5.10.233-gki-g6e61de9f5b58 #1 SMP PREEMPT (24 نوفمبر 2025) |
| إصدار Android | 15 (OriginOS 5) |
| وقت الترجمة | 2025/11/25 |
| تصحيح Android | 2025/11/01 |
| `CONFIG_FUTEX_PI` | y ✅ |
| `CONFIG_UNMAP_KERNEL_AT_EL0` | y (KPTI مفعل) |
| `kptr_restrict` | مفروض |
| `CONFIG_IO_URING` | y ✅ (مؤكد برموز vmlinux، و seccomp لا يعترض `io_uring_setup`) |
---
## 二、سلسلة الاستغلال المثالية مقابل التقدم الفعلي على 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
| المرحلة | الحالة | الوصف |
|---|---|---|
| 1. تجاوز KASLR | ✅ **تم التنفيذ** | قناة جانبية `perf_event_open` + أخذ عينات callchain (بنفس طريقة تكييف OPPO Find X6 Pro 5.15.149) |
| 2. تشغيل UAF | ✅ **تم التنفيذ** | نجح الطريق المسدود PI بثلاثة خيوط، FUTEX_CMP_REQUEUE_PI يُرجع -EDEADLK |
| 3. بدائية استعادة المكدس | ❌ **فشل معماري** | إطارات مكدس جميع استدعاءات النظام المعروفة لا تتداخل مع waiter (انظر القسم الثالث) |
| 4. الكتابة المقيدة بـ rb_erase | ❌ محظور | الشرط المسبق غير مستوفى |
| 5. الكتابة فوق inet6_protos | ❌ لم يبدأ | يعتمد على المرحلة 4 |
| 6. ROP / اختطاف تدفق التحكم | ❌ لم يبدأ | يعتمد على المرحلة 5 |
| 7. قشرة root | ❌ لم يبدأ | يعتمد على المرحلة 6 |
---
## 三、نتائج الاستنفاد الشامل لبدائية استعادة المكدس (قياسات 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 المجربة للكتابة على المكدس
| # | الطريقة | استدعاء النظام | نتيجة PD2229 | سبب الفشل الأساسي |
|---|---|---|---|---|
| 1 | `stamp_prctl` | `PR_SET_MM_MAP` | ❌ EPERM | اعتراض صارم من Android |
| 2 | `stamp_pselect` | `pselect6` (NFDS=320) | ❌ لا تداخل | waiter أسفل fd_set بـ 120B |
| 3 | `stamp_pselect` | `pselect6` (NFDS>336) | ❌ تخصيص كومة | مسار kvmalloc |
| 4 | `stamp_socket` | `MCAST_JOIN_SOURCE_GROUP` | ❌ تغطية غير كافية | يكتب حقل `lock` فقط |
| 5 | `stamp_sendmsg` | `sendmsg` | ❌ على بعد 80B من waiter | عمق إطار المكدس 0x90 غير كافٍ |
| 6 | `stamp_sendmmsg` | `sendmmsg` | ❌ على بعد 112B من waiter | إطار المكدس غير كافٍ |
| 7 | `stamp_recvmmsg` | `recvmmsg` | ❌ يصفّر task/lock | إطار 0x1d0 يدمر المؤشرات الحرجة |
| 8 | `stamp_process_vm` | `process_vm_writev` | ❌ لا تداخل | مكدس الخيط الفرعي مخصص بشكل مستقل |
| 9 | `stamp_keyctl` | `KEYCTL_INSTANTIATE_IOV` | ❌ EOPNOTSUPP | استدعاء النظام غير مدعوم + إطار مكدس 0x40 |
| 10 | `stamp_tcp` | `TCP_ZEROCOPY_RECEIVE` | ❌ إطار مكدس غير كافٍ | العمق المقدر غير كافٍ |
| 11 | `stamp_futex` | `FUTEX_CMP_REQUEUE_PI` تكراري | ❌ غير ممكن منطقيًا | يدمر نافذة UAF |
| 12 | binder ioctl | `BINDER_WRITE_READ` | ❌ EACCES | لا توجد صلاحية /dev/binder للقشرة |
| 13 | `poll` | `poll` | ❌ تخصيص كومة | pollfd على الكومة |
| 14 | `epoll_wait` | `epoll_wait` | ❌ إطار ضحل جدًا | إطار مكدس 0xE0 |
| 15 | `sched_setattr` | `sched_setattr` | ❌ عمق غير كافٍ | إطار مكدس 0xb0 |
| 16 | `timerfd_settime` | `timerfd_settime` | ❌ لا نسخ على المكدس | لا يوجد مخزن مؤقت كبير على المكدس |
| 17 | `io_uring_register` | `IORING_REGISTER_*` | ❌ **فشل مزدوج** | ①إطار المكدس 0xF0 فقط، هدف `copy_from_user` ثابت عند `sp+0x8` (فرق 424 بايت عن `sp+0x1D0` للـ waiter)؛ ②على الرغم من أن `io_uring_setup` لا يعترضه seccomp (يُرجع EFAULT بدلاً من ENOSYS)، فإن تخطيط المكدس غير متطابق |
**فشل 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
- **المستودع**: https://github.com/p2p3p/GhostLock-for-OnePlus
- **تم التحقق**: OnePlus Ace 6T (SM8845, 6.12.38) ✅
- **قابلية التطبيق على PD2229**: ❌ مثل JoinChang، عدم تطابق جيل النواة
#### YuKongA/ghostlock-oplus — OPPO Find N5/X8
- **المستودع**: https://github.com/YuKongA/ghostlock-oplus
- **النواة**: 6.6.118 GKI
- **قابلية التطبيق على PD2229**: ❌ عدم تطابق جيل النواة
#### تكييف 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 الجدول الإجمالي لمقارنة المستودعات المرجعية
| المستودع | الجهاز | SoC | النواة | طريقة استعادة المكدس | الحالة | قابلية إعادة الاستخدام على PD2229 |
|---|---|---|---|---|---|---|
| NebuSec/CyberMeowfia | Pixel 10 | - | 6.x | `PR_SET_MM_MAP` | ✅ 97% | ❌ اعتراض Android |
| JoinChang/ghostlock-oneplus | OnePlus Ace 6T | SM8845 | 6.12.38 | pselect (فرق SP=-64) | ✅ تم التحقق | ❌ عدم تطابق جيل النواة |
| p2p3p/GhostLock-for-OnePlus | OnePlus Ace 6T | SM8845 | 6.12.38 | pselect | ✅ تم التحقق | ❌ عدم تطابق جيل النواة |
| YuKongA/ghostlock-oplus | Find N5/X8 | - | 6.6.118 | pselect | ✅ | ❌ عدم تطابق جيل النواة |
| تكييف OPPO Find X6 Pro | Find X6 Pro | SM8550 | 5.15.149 | perf KASLR + ? | 🟡 KASLR ✅، ما بعده غير منشور | ❌ منصة مختلفة |
| **pubglite55/oppo-ghostlock** | **Find N2** | **SM8475** | **5.10.236** | فشل الاستنفاد | ❌ انسداد أساسي | ⚠️ **نفس المنصة ونفس الجيل، نفس المصير** |
| **harry1080/oppo-ghostlock** | **Find N2** | **SM8475** | **5.10.236** | فشل الاستنفاد | ❌ غير ممكن معماريًا | ⚠️ **نفس المنصة ونفس الجيل، نفس المصير** |
| **PD2229 (هذا التقرير)** | **PD2229** | **SM8475** | **5.10.233** | **فشل جميع المرشحين الـ 17** | ❌ **غير ممكن معماريًا** | **—** |
---
## 五、رموز وإزاحات النواة الرئيسية (قياسات vmlinux الفعلية لـ PD2229)
> العنوان الأساسي الثابت `0xffffffc008000000`، يجب إضافة انزلاق KASLR في وقت التشغيل.
| الرمز | العنوان | الاستخدام |
|---|---|---|
| `rt_mutex_start_proxy_lock` | `0xffffffc00822baa8` | نقطة دخول تشغيل الثغرة |
| `futex_wait_requeue_pi` | `0xffffffc0082d7df4` | تخصيص waiter، إطار مكدس 0x1b0 |
| `__arm64_sys_futex` | `0xffffffc0082dfe9c` | إطار مكدس 0x90 |
| `do_futex` | `0xffffffc0082d0768` | إطار مكدس 0xc0 |
| `core_sys_select` | `0xffffffc008634cf0` | إطار مكدس pselect 0x1c0 |
| `____sys_sendmsg` | `0xffffffc0093eda88` | إطار مكدس 0x90 |
| `do_recvmmsg` | `0xffffffc0093ef49c` | إطار مكدس 0x1d0 |
| `__arm64_sys_io_uring_register` | `0xffffffc008aae328` | إطار مكدس 0x10+0x70 |
| `__io_uring_register` | `0xffffffc008aae5f8` | إطار مكدس 0x80 |
| `inet6_protos` | `0xffffffc00ab0a278` | هدف الكتابة في المرحلة 4 |
| `selinux_state` | `0xffffffc00aee8c70` | هدف تعطيل SELinux |
| `init_task` | `0xffffffc00ab0c240` | مصدر قراءة cred |
### بنية rt_mutex_waiter (تخصيص vivo 5.10.233)
```c
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 بايت)
```
---
## 六、ما تم تنفيذه مقابل ما يجب تنفيذه
### ✅ البنية التحتية المنفذة
1. **تجاوز KASLR** — `perf_event_open` + أخذ عينات callchain (بنفس طريقة OPPO Find X6 Pro 5.15.149)
2. **تشغيل UAF** — طريق مسدود PI بثلاثة خيوط، FUTEX_CMP_REQUEUE_PI يُرجع -EDEADLK
3. **جدول رموز كامل** — التحقق من 103+ رمزًا عبر IDA (بمنهجية استخراج 103/103 الخاصة بـ JoinChang)
4. **تخطيط بنية rt_mutex_waiter** — تأكيد إزاحات تخصيص vivo
5. **تحليل دقيق لتخطيط إطار المكدس** — اكتمل حساب أعماق مسارات futex و pselect/io_uring
6. **الاستبعاد الشامل لـ 17 مرشحًا لاستعادة المكدس** — إنشاء مصفوفة "غير ممكن" كاملة
### ❌ غير منفذ (الانسداد الأساسي)
1. **بدائية استعادة المكدس** — تخطيط مكدس مترجم SM8475 5.10 GKI يجعلها غير قابلة للاستخدام معماريًا
2. **بدائية الكتابة المقيدة** — لا يمكن تشغيل rb_erase بسبب فشل استعادة المكدس
3. **جميع المراحل اللاحقة** — انسداد متسلسل
---
## 七、الاستنتاج النهائي
> ⚠️ **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 مرشحًا لاستعادة المكدس
## 九、فهرس المستودعات المرجعية
| المستودع | الرابط | القيمة الرئيسية |
|---|---|---|
| NebuSec/CyberMeowfia | https://github.com/NebuSec/CyberMeowfia | إطار الاستغلال الأصلي، نسبة نجاح 97% |
| JoinChang/ghostlock-oneplus | https://github.com/JoinChang/ghostlock-oneplus | تكييف ناجح على 6.12 GKI، منهجية استخراج 103 إزاحة |
| p2p3p/GhostLock-for-OnePlus | https://github.com/p2p3p/GhostLock-for-OnePlus | سلسلة استغلال كاملة على 6.12 GKI |
| YuKongA/ghostlock-oplus | https://github.com/YuKongA/ghostlock-oplus | تكييف OPPO على 6.6 GKI |
| pubglite55/oppo-ghostlock | https://github.com/pubglite55/oppo-ghostlock | **مرجع فشل على نفس المنصة SM8475 5.10.236** |
| harry1080/oppo-ghostlock | https://github.com/harry1080/oppo-ghostlock | **مرجع فشل على نفس المنصة SM8475 5.10.236** |
| التحليل التقني لـ NebuSec | https://nebusec.ai/research/ionstack-part-2/ | تفاصيل تقنية السلسلة الأصلية لـ GhostLock |
| الإصلاح العلوي | commit 3bfdc63936dd | كود الإصلاح |
---