CVE-2026-43499 (GhostLock) — HUAWEI MatePad Pro 11 GOT-W29

بحث تصعيد الامتيازات لـ CVE-2026-43499 (rtmutex/futex-PI UAF، "GhostLock") على GOT-W29 (HarmonyOS 4.0، kernel 4.19.157-perf+).

الاستنتاجات الأساسية:

• تم التحقق من بدائية الكتابة للثغرة بنجاح على الجهاز الحقيقي (إعادة كتابة sysctl_bootid في النواة بمساعدة KPM، واستنتاج KASLR slide).
• لكن التصعيد الحقيقي (shell بدون KPM وبدون RT) غير ممكن: مسار إرجاع pselect في نواة 4.19 يستبدل بشكل حتمي كلمة lock في overlay، ولا يوجد ناقل بديل. هذا طريق مسدود تحدده هندسة المكدس في النواة، وليس عيبًا في التنفيذ (بالمقارنة، يمكن تصعيد الامتيازات بالكامل على أجهزة smt878u/popsicle بسبب اختلاف هندسة المكدس).

الجهاز

الثغرة

في kernel/locking/rtmutex.c، تستخدم الدالة remove_waiter() في مسار التراجع عن rt_mutex_start_proxy_lock() المتغير current بدلاً من waiter->task للتنظيف، مما يؤدي إلى pi_blocked_on معلق (stack UAF). تؤثر على 2.6.39 ~ 7.1 (هذه النواة ضمن النطاق). الإصلاح الرسمي في commit 3bfdc63936dd.

تم التأكيد على هذا الجهاز: الكود المصدري rtmutex.c:1110-1112، وفك تجميع boot.elf، والتحفيز على الجهاز الحقيقي — كلها تم التحقق منها.

التحفيز

آلية تحفيز الثغرة

إنشاء حلقة PI لجعل FUTEX_CMP_REQUEUE_PI يُرجع -EDEADLK، مما يؤدي إلى التراجع وتشغيل خطأ remove_waiter، تاركًا pi_blocked_on معلقًا (يشير إلى rt_waiter على مكدس نواة خيط waiter).

لماذا فشل التحفيز القديم

كان التحفيز القديم يجعل waiter يمتلك futex هدف إعادة التوجيه بنفسه (self-own)، مما يصادف بالضبط فحص owner==task المبكر في task_blocks_on_rt_mutex في هذه النواة (boot.elf 0x3808-0x3868)، ويعود قبل كتابة pi_blocked_on → لا يتم إنشاء مؤشر معلق أبدًا → وضع overlay كان تشخيصًا خاطئًا (بدون انهيار + boot_id بدون تغيير).

التحفيز الصحيح (حلقة PI، تم تنفيذه)

حلقة PI: المالك FUTEX_LOCK_PI(target) يمتلك هدف إعادة التوجيه؛ waiter يمتلك chain futex؛ ثم يمنع المالك نفسه على chain (الحلقة: waiter→target→owner→chain→waiter). أثناء إعادة التوجيه، يكتشف فحص السلسلة rt_mutex_owner(chain)==top_task → -EDEADLK → التراجع يمسح pi_blocked_on للشخص الخطأ → يصبح pi_blocked_on الخاص بـ waiter معلقًا. يجب خفض أولوية المالك (nice=10) بحيث يختلف prio بعد boost عن owner_waiter->prio، وإلا فسيحدث خروج مبكر في rt_mutex_waiter_equal.

النتائج

تسريب KASLR (perf_event_open)

في shell (uid 2000) مع perf_event_paranoid=-1، يقوم perf_event_open(PERF_SAMPLE_IP, exclude_user=1) بأخذ عينات من مجموعة عناوين نص النواة، ومحاذاتها مع إزاحات الرموز المعروفة للحصول على slide.

samples=27651 kernel_ips=1685 lo=0xffffff948728176c hi=0xffffff9488ebfc7c
KASLR slide=0x147f200000    (40/40 IP mapped into kernel text region verified)
runtime _stext=0xffffff9487280800

الأداة: tools/perf_kaslr.c. المتطلبات المسبقة: shell (Shizuku rish)، بدون اعتراض seccomp.

تحفيز EDEADLK

[M] CMP_REQUEUE_PI ret=-1 errno=35 (EDEADLK!)
[W] WAIT_REQUEUE_PI ret=-1 errno=110 (ETIMEDOUT)  ← waiter returned
[M] waiter_returned=1                              ← left dangling pi_blocked_on

الأداة: tools/edeadlk_probe.c (variant 8+2+1 = 11، أو 27).

آلية بدائية الكتابة

في rt_mutex_adjust_prio_chain الخطوة [7]، يتم تنفيذ rb_erase على fake waiter (مسار فرع أيسر واحد): *(tree_left) = tree_pc + كتابة تدريجية __rb_change_child. جميع الإزاحات في target.h تم قياسها من فك تجميع boot.elf.

الإزاحات الكاملة

انظر exploit/ghostlock-source/src/target.h. النقاط الرئيسية:

• task_struct: cred=0x988, prio=0x184, pi_blocked_on=0xa90, usage=0x68, mm=0x728
• rt_mutex_waiter (HW_FUTEX_PI): tree@0x0, pi_tree@0x18, task@0x30, lock@0x38, major@0x40, prio@0x48, deadline@0x50
• PAGE_OFFSET=0xffffffc000000000, PHYS_OFFSET=0x80000000 (kona), KIMAGE_TEXT_BASE=0xffffff8008080000

التحقق من بدائية الكتابة على الجهاز الحقيقي

وحدة KPM مكتوبة ذاتيًا (tools/kpm-debug/rtmutex-dbg.c، KernelPatch 0.13.5 inline-hook) تعيد بناء overlay (tree/task/lock) أثناء المسار الوهمي وتعيد كتابة معامل next_lock إلى empty_zero_page (يستخدم KernelPatch _transit8 الدالة الأصلية مع fargs المعدلة)، بحيث يمر [3] next_lock==waiter->lock في rt_mutex_adjust_prio_chain، وينجح [5] trylock على قفل صفري، و[6] بدون مالك، ويتم تنفيذ [7] rt_mutex_dequeue (rb_erase بفرع أيسر واحد) — تمت إعادة كتابة sysctl_bootid إلى &loggers[0][1]، slide-kaslr-ok.

REPAIR3 waiter=0xffffff801ecdbc00 lock=0xffffffa7c4950000
slide boot_id_leaked_nfulnl_logger value=ffffffa7c4612320
slide-kaslr-ok base=ffffffa7c1280000 slide=00000027b9200000

تصميم Overlay

هندسة المكدس مؤكدة من أحجام إطارات boot.elf: rt_waiter في __arm64_sys_futex(0x70) + do_futex(0x60+0x1a0) عند sp+0xc0 → العمق 0x1b0؛ stack_fds[0] في مسار pselect عند العمق 0x210، الفرق 0x60 = 12 كلمة. لذلك تقع word_i في stack_fds[12+i]: الكلمات 0-2 في منطقة إدخال ex[2..4] (قابلة للتحكم المباشر)، الكلمات 6-7 (task/lock) في res_in[3..4] (مشفرة باستخدام in[3..4] + fd جاهز POLLIN)، الكلمات 3-5/8-10 تُترك 0. يعود pselect فورًا بسبب fd الجاهز → ينتظر waiter في وضع المستخدم بحلقة انتظار (بدون إشارات، بدون syscalls) حتى يكمل المستهلك.

لماذا التصعيد الحقيقي غير ممكن

1. كلمة lock في ناقل pselect يتم استبدالها في مسار الإرجاع

تقع كلمتا task/lock في overlay في res_in[3]/[4] (مشفرة بجاهزية fd). تم قياس أن res_in[4] (lock) يتم استبدالها بشكل حتمي في مسار إرجاع pselect (بقايا إطار rt_sigreturn)، ولا تساوي أبدًا fake_lock في الحمولة؛ res_in[3] (task) سليمة أحيانًا. يمكن للتجنب في وضع المستخدم (عمليات FP + sched_yield) فقط خفض معدل تشغيل do_notify_resume إلى ~21%، لكن استبدال lock شبه مؤكد.

حقيقتان إضافيتان ذات صلة:

• مسار بدون مالك محجوب في 4.19: rt_mutex_adjust_pi() يحتوي على if (!owner) return 0;، ولا يتم استدعاء adjust_prio_chain عندما لا يملك fake_lock مالكًا. لا يحتوي popsicle (6.12) على هذا الفحص. تم نقل حمولة مع مالك (fake_lock owner=fake_task|1)، لكن لا يمكن تشغيلها بشكل موثوق لأن كلمة lock سيتم استبدالها حتمًا.
• لا يمكن استخدام empty_zero_page كهدف كتابة قسري: كتابتها تدمر الصفحة الصفرية المشتركة للنظام → عاصفة oops بعد الاختبار.

2. الناقل البديل (ppoll) غير ممكن على مستوى الترميز

بعد فك تجميع __arm64_sys_ppoll / do_sys_poll في boot.elf تم التأكيد: pollfd هو بنية من 16 بايت (fd 4B + events 4B + revents 4B + pad 4B)، ولا يمكنها حمل كلمتي task/lock (64 بت) لـ fake waiter — قيمة fd محدودة (يجب أن تكون fd حقيقية)، events فقط 4 بايت وغير متصلة، revents مكتوبة بواسطة النواة (غير قابلة للتحكم).

3. الاختلاف عن الأجهزة الأخرى

يمكن تصعيد الامتيازات بالكامل على smt878u / popsicle: هندسة المكدس لديهم تسمح بوقوع الكلمات في in/out/ex القابلة للتحكم من قبل المستخدم (3 مجموعات fd في pselect). موضع waiter في GOT-W29 (bits+0x60 → task/lock في res_in[3]/[4]) لا يحتوي على هذه النافذة. هذا اختلاف في هندسة مكدس النواة، وليس عيبًا في التنفيذ.

4. قيود نطاق التطبيق العادي

لا توجد قناة KASLR جاهزة في نطاق التطبيق (untrusted_app) (perf/kallsyms/pagemap/dmesg كلها مرفوضة)؛ يُرجع CMP_REQUEUE_PI القيمة 1 (نجاح إعادة التوجيه) ولا يمر عبر تراجع EDEADLK؛ major_only في cpuset غير الجذر يقصر دائرة الخطوة [6] بشكل صارم. المدخل الوحيد لتغيير QOS /dev/iaware_qos_ctrl مرفوض بواسطة SELinux. لذلك لا يمكن لتطبيق عادي تشغيل هذه الثغرة.

سلسلة أدوات التصحيح

وحدة KernelPatch مكتوبة ذاتيًا (rtmutex-dbg) لمراقبة fake waiter وبدائية الكتابة على الجهاز الحقيقي، مبنية على ملفات رأس LyraVoid/KernelPatch 0.13.5 (نفس مصدر FolkPatch).

مجموعة hooks

الترجمة

cd <KernelPatch>/kpms/rtmutex-dbg
make TARGET_COMPILE=aarch64-linux-android- \
  CC=$PREFIX/bin/aarch64-linux-android-clang \
  LD=$PREFIX/bin/aarch64-linux-android-ld

الناتج rtmutex_dbg.kpm. يجب أن تتضمن أعلام الترجمة -fno-pic -fno-pie -fno-asynchronous-unwind-tables -fno-unwind-tables (مضمنة بالفعل في Makefile): ينتج clang افتراضيًا PIC مع إعادة توطين GOT، وينتج افتراضيًا .eh_frame (R_AARCH64_PREL32) — لا يدعم محمل KPM أيًا منهما → فشل التحميل -1.

التحميل

المفتاح الفائق لـ FolkPatch هو su (وليس KernelPatch الافتراضي في APatch). استخدم أداة sc_kpm_load (الكود المصدري sc_kpm_load.c):

adb shell /data/local/tmp/sc_kpm_load su /sdcard/Download/rtmutex_dbg.kpm  # تحميل
adb shell /data/local/tmp/sc_kpm_load unload rtmutex-dbg su               # إلغاء التحميل
adb shell /data/local/tmp/sc_kpm_load ctl rtmutex-dbg counts su           # العدادات

اختبار بنقرة واحدة

run_rtmdbg_test.sh (على الجهاز /data/local/tmp/ghostlock-test/): تشغيل GhostLock بهوية shell (المسار الحقيقي GOT_SLIDE_NO_RT=1)، حلقة مزامنة 0.5s لمنع فقدان السجلات، dmesg -w على القرص، جمع تلقائي بعد 90s (SIGSTOP لمنع إعادة التشغيل بسبب soft-lock). قبل الاختبار:

adb shell 'su -c "sh /sdcard/ghostlock-test/set_debug_no_reboot.sh"'  # منع إعادة التشغيل

نقاط المراقبة (dmesg [RTMDBG])

• REPAIR3: إعادة بناء overlay وإعادة كتابة معامل next_lock أثناء التحقق من بدائية الكتابة
• FAKEWALK skip: تخطي المسار الوهمي المغطى (بدون كتابة وبدون انهيار)
• prio_chain[N] / prio_chain_ret: استدعاءات المسار وقيم الإرجاع (0=اكتمل؛ 4294967261=-EDEADLK)
• do_select n=320: res_in[3]/[4] من جانب النواة
• futex op=13/14: CMP_REQUEUE_PI / WAIT_REQUEUE_PI

سجلات oops/panic الكاملة من HUAWEI في /data/log/bbox/history.log.

الدليل

tools/      أدوات التحقق (perf KASLR, مسبار EDEADLK, سلسلة أدوات KPM)
target/     جميع الإزاحات المقاسة
exploit/    slide.c المنقول (بما في ذلك تعديلات تحفيز EDEADLK)

الشكر والتقدير

• PoC الرسمي: x-spy/CVE-2026-43499-popsicle, soralis0912/CVE-2026-43499-aristotle, JoinChang/ghostlock-oneplus, Wtrwx/smt878u-ionstack-poc (GPL-3.0)
• CVE: NVD, Red Hat RHSB-2026-010