0xcyberstan/cve-2026-59346-pocPoC لـ CVE-2026-59346 - تجاوز سعة عدد صحيح 32-بت في مسار تقسيم TSO الخاص بـ VMXNET3 من VMware، انهيار من الضيف إلى المضيف.
إثبات مفهوم لثغرة تجاوز سعة عدد صحيح 32-بت في مسار تقسيم TSO لبطاقة الشبكة الافتراضية VMXNET3 في vmware-vmx، يمكن الوصول إليها من جهاز ضيف VM.
تم تصحيح هذه المشكلة. نُشر إثبات المفهوم لأغراض البحث والدفاع فقط. يُسبب انهيارًا على جانب المضيف (SIGSEGV) ولا يحاول تنفيذ أي كود.
| CVE | CVE-2026-59346 |
| التحليل التفصيلي | cyberstan.co.uk/vmxnet3-tso-overflow |
| إشعار ZDI | ZDI-26-647 |
| إشعار المورّد | VMSA-2026-0007 |
| CVSSv3 | 9.3 (المورّد) / 7.5 (ZDI) |
| تم الإصلاح في | Workstation / Fusion 26H1u1 |
| تم الإبلاغ عبر | Trend Micro Zero Day Initiative |
تحسب روتين تقسيم TSO في VMXNET3 حجم التخصيص الخاص به على أنه seg_count * per_seg_size باستخدام imul بعرض 32-بت. عندما يتجاوز الناتج الحقيقي 2^32 فإن النتيجة تلتف، ويستقبل المخصِّص القيمة المقتطعة. حلقة التقسيم التي تلي ذلك تُدار بواسطة seg_count، وليس بواسطة حجم التخصيص، لذا تكتب per_seg_size بايت لكل مقطع في مخزن حجمه مبني على الناتج الملتف.
أضاف إصلاح سابق لهذا المسار البرمجي (CVE-2025-41236) فحوصات حدودية ترفض الحزم التي يتجاوز فيها MSS أو per_seg_size أو مجموعهما 9216. تقيّد تلك الفحوصات حقول الوصف الفردية لكنها لا تقيّد الناتج أبدًا، وهو القيمة التي تلتف فعليًا. لا تزال المعاملات الأقل بكثير من حد 9216 تصل إلى التجاوز.
تحليل السبب الجذري الكامل، والتفكيك المشروح، وهندسة الكومة: cyberstan.co.uk/vmxnet3-tso-overflow.
يمكن لمستخدم ضيف يمتلك صلاحية كافية لكتابة واصفات TX الخام أن يُسبب كتابة كبيرة خارج الحدود في عملية vmware-vmx على المضيف بمحتوى مستمد من الحزمة المقدَّمة من الضيف. في إثبات المفهوم هذا تستمر الكتابة حتى تصل إلى ذاكرة غير معيَّنة وتموت عملية المضيف بـ SIGSEGV، مما يؤدي إلى إيقاف تشغيل VM.
صنّف المورّد المشكلة على أنها تسمح بتنفيذ كود عشوائي في سياق الـ hypervisor؛ لكن إثبات المفهوم المنشور يُظهر انتهاك أمان الذاكرة فقط ويتوقف عند الانهيار.
جميع منتجات hypervisor المكتبية من VMware التي تشترك في الواجهة الخلفية VMXNET3 الخاصة بـ vmware-vmx: Workstation وFusion وPlayer. يُعد VMXNET3 المحوّل الافتراضي للأجهزة الضيفة الحديثة. راجع VMSA-2026-0007 للحصول على القائمة الموثوقة للإصدارات المتأثرة.
إثبات المفهوم هو وحدة نواة Linux تعمل داخل الجهاز الضيف. تكتب واصفات حلقة TX الخاصة بـ VMXNET3 مباشرة، متجاوزةً منطق TSO في السائق داخل النواة، ثم تقرع سجل doorbell MMIO.
# Inside the guest VM, as root:
# Kernel headers
apk add linux-virt-dev # Alpine
# apt install linux-headers-$(uname -r) # Debian / Ubuntu
make
insmod vmxnet3_tso_trigger.ko
ستنهار عملية vmware-vmx على المضيف وسيُغلق الجهاز الضيف. توقّع فقدان أي حالة غير محفوظة في VM، وخُذ لقطة أولًا إذا أردت إعادة تشغيله.
يحتاج الجهاز الضيف إلى محوّل VMXNET3. تحقق باستخدام lspci | grep -i vmxnet أو تأكد من ethernet0.virtualDev = "vmxnet3" في ملف .vmx. تتحدث الوحدة مع بطاقة الشبكة مباشرة، لذا يجب أن تكون الواجهة قيد التشغيل ومرتبطة بسائق vmxnet3.
| المعامل | الافتراضي | الغرض |
|---|---|---|
ifname | eth0 | الواجهة المدعومة بمحوّل VMXNET3 |
dryrun | 0 | 1 يكتب الواصفات لكنه يتخطى doorbell، فلا يُفعَّل أي شيء |
wait_ms | 0 | تأخير بالمللي ثانية بين إعداد الواصفات وكتابة doorbell |
txwarm | 0 | حزم TSO لدفعها عبر الحلقة قبل حزمة التجاوز |
warmup | 0 | تخصيصات على جانب المضيف لإصدارها قبل التشغيل |
freechunk | 0 | تخصيصات بنفس الحجم لإنشائها وتحريرها جزئيًا قبل التشغيل |
يشكّل warmup وfreechunk كومة المضيف قبل حدوث التجاوز. لا حاجة إليهما لإعادة إنتاج الانهيار؛ اتركهما على صفر ما لم تكن تحقق في تخطيط التخصيص.
ابدأ بتشغيل تجريبي للتأكد من أن الوحدة تجد الحلقة وتحسب المعاملات، دون لمس المضيف:
insmod vmxnet3_tso_trigger.ko dryrun=1
dmesg | tail -20
rmmod vmxnet3_tso_trigger
يتضمن الناتج المتوقع الهندسة المحسوبة وحلقة TX المحددة:
tso_v8: per_seg=6240 (0x1860), HDR_TOTAL=6222, MSS=1
tso_v8: PARAMS: alloc=... overflow=... seg_count=... paylen=...
tso_v8: ring at priv+N: base=... sz=... n2f=... gen=...
tso_v8: DRYRUN -- descriptors written but NOT triggered
إذا لم تُعثر على الحلقة فستسجل الوحدة TX ring not found وتتوقف. يعني ذلك عادةً اختلافًا في تخطيط السائق؛ تحتاج الاستدلالية البحثية في find_tx_ring() إلى تعديل لتلك النواة.
ثم شغّله فعليًا، على واجهة غير افتراضية إذا لزم الأمر:
insmod vmxnet3_tso_trigger.ko ifname=eth1
يموت الجهاز الضيف مع عملية المضيف، لذا قد لا تصل الرسائل الأخيرة إلى القرص. لالتقاطها، راقب الطرفية بدلًا من الاعتماد على السجل:
dmesg -w
أكّد الانهيار من جانب المضيف في vmware.log الخاص بـ VM، والذي سيُظهر PANIC: Unexpected signal: 11 مع تتبع عكسي عبر المخصِّص على خيط vcpu-0.
ifname جهاز VMXNET3، وليس جسرًا أو محوّل e1000 ثانويًا.need N entries but ring has M slots إذا لم تستطع حلقة TX استيعاب سلسلة الواصفات.| المضيف | Ubuntu 24.04 LTS، نواة 6.17.0، glibc 2.39 |
| الـ hypervisor | VMware Workstation Pro 25.0.1 (build 25219725) |
| الجهاز الضيف | Alpine Linux، نواة 6.12، بطاقة VMXNET3 |
إزاحات الرموز المشار إليها في التحليل خاصة بالبناء 25219725. النمط القابل للاستغلال هو نفسه عبر البُنى، لكن الإزاحات ستختلف.
vmxnet3_tso_trigger.c trigger module
Makefile out-of-tree kernel module build
يجب إجراء عملية الضرب بعرض 64-بت، مع تقييد الناتج قبل وصوله إلى المخصِّص. تقييد حقول الوصف الفردية ليس كافيًا، لأن التجاوز خاصية للناتج وليس لأي من المعاملين.
| التاريخ | الحدث |
|---|---|
| 2026 | تم الإبلاغ إلى Trend Micro ZDI |
| سبتمبر 2026 | تم التصحيح بواسطة Broadcom في 26H1u1 (VMSA-2026-0007) |
| سبتمبر 2026 | نُشر ZDI-26-647 |
نُشر بموجب الإفصاح المنسّق، بعد إصدار الإصلاح. شغّله فقط ضد الأنظمة التي تملكها أو المصرّح لك باختبارها. سيُسبب انهيار عملية الـ hypervisor على المضيف، لذا لا توجّهه نحو أي شيء تهتم به.
Stan S - cyberstan.co.uk · @0xCyberstan