في وقت سابق، نشر فريق Google Project Zero سلسلة استغلال لهاتف Pixel 9 أثبتت أن الوصول من هجوم Zero-Click إلى صلاحيات root على أندرويد يمكن أن يتم عبر ثغرتين فقط.
إحدى هذه الثغرات كانت في مكوّن Dolby وتحمل المعرّف CVE-2025-54957. وكانت تؤثر على أجهزة أندرويد قبل أن يتم إصلاحها في يناير 2026.
بعد نجاح السلسلة على Pixel 9، كان السؤال الطبيعي هو: هل يمكن بناء سلسلة مشابهة على Pixel 10؟
الإجابة كانت نعم، لكن الطريق إلى النواة تغيّر بالكامل.
#تحديث استغلال Dolby
نقل استغلال CVE-2025-54957 من Pixel 9 إلى Pixel 10 لم يكن معقدًا بشكل كبير.
معظم العمل تمثل في تحديث الإزاحات Offsets المستخدمة داخل مكتبة Dolby، لأن إصدار المكتبة في Pixel 10 يختلف عن الإصدار الموجود في Pixel 9.
لكن ظهر اختلاف مهم في آليات الحماية.
هاتف Pixel 10 يستخدم RET PAC بدلًا من الاعتماد على -fstack-protector في هذا الجزء من الكود.
نتيجة لذلك لم تعد الدالة __stack_chk_fail متاحة كهدف مناسب للاستبدال أثناء الاستغلال.
بعد عدة محاولات، استخدم الباحثون الدالة dap_cpdp_init كبديل.
هذه الدالة يتم استدعاؤها مرة واحدة أثناء تهيئة الـ decoder، ثم لا يتم استخدامها مرة أخرى، مما جعل تعديلها أقل تأثيرًا على عمل المكوّن.
النسخة المحدثة من استغلال Dolby تعمل فقط على الأجهزة غير المحدثة التي تستخدم Security Patch Level لشهر ديسمبر 2025 أو أقدم.
#اختفاء BigWave وظهور VPU
المرحلة الثانية من سلسلة Pixel 9 كانت تعتمد على ثغرة داخل تعريف BigWave للوصول إلى صلاحيات أعلى.
لكن عند الانتقال إلى Pixel 10 ظهرت مشكلة واضحة.
تعريف BigWave لم يعد موجودًا على الجهاز.
بدلًا منه ظهر تعريف جديد يمكن الوصول إليه من سياق SELinux الخاص بـ mediacodec عبر المسار:
/dev/vpu
هذا التعريف مسؤول عن التواصل مع وحدة Chips&Media Wave677DV الموجودة داخل شريحة Tensor G5.
وظيفة هذه الوحدة هي تسريع عمليات فك ترميز الفيديو.
وبحسب التعليقات الموجودة في الكود مفتوح المصدر، فإن تعريف VPU طُوّر بواسطة نفس الفريق الذي عمل سابقًا على BigWave.
هنا بدأ التدقيق.
وخلال ساعتين فقط من مراجعة الكود، اكتشف الباحث Seth Jenkins بالتعاون مع Jann Horn ثغرة خطيرة وبسيطة بشكل لافت.
#ثغرة أقرب إلى الحلم بالنسبة لمطور Exploit
الجزء المسؤول عن mmap داخل تعريف VPU كان بالشكل التالي:
static int vpu_mmap(struct file *fp, struct vm_area_struct *vm)
{
unsigned long pfn;
struct vpu_core *core =
container_of(fp->f_inode->i_cdev, struct vpu_core, cdev);
vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM_DONTDUMP);
vm->vm_page_prot = pgprot_device(vm->vm_page_prot);
pfn = core->paddr >> PAGE_SHIFT;
return remap_pfn_range(
vm,
vm->vm_start,
pfn,
vm->vm_end - vm->vm_start,
vm->vm_page_prot
) ? -EAGAIN : 0;
}
وظيفة هذا الكود هي السماح لعملية في User Space بربط منطقة سجلات MMIO الخاصة بوحدة VPU داخل مساحة الذاكرة الافتراضية للعملية.
المشكلة أن حجم المنطقة المطلوبة لا يتم تقييده بحجم منطقة MMIO الحقيقية.
الدالة remap_pfn_range تحصل على طول الـ VMA مباشرة عبر:
vm->vm_end - vm->vm_start
ولا يوجد تحقق فعلي يضمن أن الحجم المطلوب يقع داخل الحدود المسموح بها.
هذه التفاصيل الصغيرة غيّرت كل شيء.
#من MMIO إلى الذاكرة الفيزيائية
إذا طلبت العملية حجمًا أكبر من منطقة سجلات VPU، فإن النواة ستستمر في إنشاء Mapping للصفحات الفيزيائية التي تأتي بعدها.
بمعنى آخر، المهاجم لا يحصل فقط على سجلات الـ VPU.
يمكنه توسيع الـ mapping والوصول إلى أجزاء أخرى من الذاكرة الفيزيائية.
والأخطر أن صورة Linux Kernel نفسها موجودة في عنوان فيزيائي أعلى من منطقة VPU.
بالتالي يمكن الوصول إلى مناطق مثل:
.text
.data
من User Space.
وهذا يعني عمليًا الحصول على قدرة قراءة وكتابة مباشرة على ذاكرة النواة.
#عندما تصبح النواة قابلة للكتابة
بمجرد امتلاك Arbitrary Kernel Read/Write تصبح مرحلة تصعيد الصلاحيات مختلفة تمامًا.
لم تعد هناك حاجة إلى بناء سلسلة معقدة من الـ primitives.
يمكن تعديل دالة داخل النواة أو تغيير بيانات حساسة للوصول إلى تنفيذ كود بصلاحيات Kernel.
ما جعل الوضع أسوأ هو أن عنوان Kernel الفيزيائي على أجهزة Pixel كان ثابتًا في هذا السياق البحثي.
لذلك لم يكن الباحث بحاجة إلى البحث عن النواة داخل الذاكرة التي تم ربطها.
كان يعرف مسبقًا الإزاحة بين منطقة VPU ومكان وجود Kernel.
الشرط الوحيد هو طلب VMA كبيرة بما يكفي لتصل إلى تلك المنطقة.
بحسب Project Zero، الحصول على قدرة قراءة وكتابة عشوائية على Kernel احتاج إلى نحو خمس أسطر فقط من الكود.
أما بناء الاستغلال الكامل للثغرة فاستغرق أقل من يوم.
وهذا يوضح مدى خطورة الخطأ.
#لماذا هذه الثغرة خطيرة جدًا؟
المشكلة ليست مجرد Memory Corruption تقليدية تحتاج إلى Heap Grooming أو Race Condition أو تجاوز عدة آليات حماية.
التعريف نفسه يمنح العملية طريقًا مباشرًا تقريبًا إلى الذاكرة الفيزيائية.
الثغرة تسمح بتوسيع Mapping مصمم لمنطقة Hardware Register صغيرة إلى نطاق أكبر بكثير.
وبمجرد وصول هذا النطاق إلى Kernel Memory، تصبح حدود العزل بين User Space وKernel Space قابلة للتجاوز.
من منظور أمني، هذا النوع من الأخطاء قريب من أسوأ ما يمكن أن يوجد داخل Kernel Driver.
#سلسلة الاستغلال على Pixel 10
السلسلة النهائية أصبحت واضحة.
المرحلة الأولى تبدأ من ثغرة Dolby التي تسمح بالوصول إلى سياق قابل للاستغلال بدون أي تفاعل من المستخدم.
بعد ذلك يتم الوصول إلى تعريف:
/dev/vpu
ومن خلال خلل mmap يتم إنشاء Mapping يتجاوز منطقة MMIO المخصصة للجهاز.
بعدها يصل المهاجم إلى Kernel Memory ويحصل على Arbitrary Read/Write.
النتيجة النهائية هي الانتقال من Zero-Click إلى Kernel Code Execution ثم السيطرة الكاملة على الجهاز.
كل ذلك باستخدام ثغرتين فقط.
#مسار الإصلاح
تم الإبلاغ عن ثغرة VPU إلى Google في 24 نوفمبر 2025.
فريق Android Vulnerability Rewards Program صنفها بدرجة High.
هذا التصنيف كان أفضل من التعامل الأولي مع ثغرة BigWave السابقة، التي كانت تحمل تأثيرًا أمنيًا مشابهًا ولكنها صُنفت في البداية بدرجة Moderate.
تم إصلاح الثغرة بعد 71 يومًا من تاريخ الإبلاغ عنها.
ووصل الإصلاح ضمن تحديثات أمان Pixel لشهر فبراير 2026.
بالنسبة إلى ثغرة داخل Android Driver، اعتبر الباحث هذا التحسن ملحوظًا.
خصوصًا أن الإصلاح تم خلال أقل من 90 يومًا من معرفة الشركة بالمشكلة.
#الجانب الإيجابي لاكتشاف مثل هذه الثغرات
الهدف من أبحاث Project Zero لا يقتصر على إصلاح ثغرة منفردة.
الهدف الأهم هو دفع الشركات إلى تحسين دورة تطوير البرمجيات نفسها.
في هذه الحالة، سرعة التعامل مع ثغرة VPU تشير إلى تحسن واضح في عملية فرز الثغرات وإصلاحها داخل منظومة Android.
هذا النوع من التحسن يقلل فترة تعرض المستخدمين للخطر.
كما يساعد على رفع مستوى الاستجابة للثغرات التي تؤثر على مكونات منخفضة المستوى مثل Drivers وFirmware Interfaces.
#لكن المشكلة الأعمق ما زالت موجودة
رغم سرعة الإصلاح، فإن وجود الثغرة من الأساس يطرح سؤالًا أكبر.
بعد اكتشاف مشكلات خطيرة سابقًا في BigWave، كان من المتوقع مراجعة التعريفات الأخرى التي طورها الفريق نفسه.
لكن بعد نحو خمسة أشهر فقط، تم العثور على ثغرة شديدة الوضوح في تعريف VPU خلال ساعتين من التدقيق.
وهذا يعني أن المشكلة ليست مرتبطة بثغرة واحدة.
المشكلة تتعلق بمدى دمج الممارسات الأمنية داخل تطوير Kernel Drivers.
التعريفات التي تتعامل مع MMIO وDMA والذاكرة الفيزيائية يجب أن تُعامل كأحد أكثر أجزاء النظام حساسية.
خطأ واحد في التحقق من الحدود قد يحول واجهة Hardware عادية إلى بوابة مباشرة إلى Kernel.
#ما الذي يجب أن تتعلمه فرق التطوير؟
لا يكفي انتظار الباحثين لاكتشاف الأخطاء بعد طرح المنتج.
المكونات الحساسة يجب أن تمر بمراجعة أمنية متخصصة قبل وصولها إلى المستخدم.
أي Driver يسمح بـ mmap أو يتعامل مع Physical Memory يحتاج إلى تحقق صارم من العنوان والطول والصلاحيات.
كما يجب مراجعة جميع التعريفات التي كتبها الفريق نفسه عند اكتشاف نمط أمني ضعيف في أحدها.
إصلاح الثغرة الحالية خطوة جيدة.
لكن منع الفئة نفسها من الثغرات أهم بكثير من إصلاح كل حالة بشكل منفصل.
#الخلاصة
سلسلة Pixel 10 توضح كيف يمكن أن تتغير طريقة الاستغلال بينما تبقى النتيجة النهائية نفسها.
اختفى BigWave، لكن ظهر VPU.
أُغلق باب، لكن نافذة أخرى فُتحت.
والنافذة هذه المرة كانت خطيرة بشكل استثنائي.
بضعة أسطر ناقصة للتحقق من حدود mmap كانت كافية لفتح الوصول إلى الذاكرة الفيزيائية والوصول إلى Kernel.
هذه الحالة تذكير مهم بأن قوة أنظمة الحماية الحديثة لا تلغي خطورة الأخطاء البسيطة في المكونات منخفضة المستوى.
في بعض الأحيان لا يحتاج المهاجم إلى تجاوز عشر طبقات من الحماية.
يحتاج فقط إلى Driver وثق بالمدخلات أكثر مما ينبغي.
