CVE-2026-16512 in Zephyr
الملخص
بحسب VulDB • 20/09/2026
يؤدي دالة `gptp_handle_msg()` الموجودة في الملف الفرعي `subsys/net/l2/ethernet/gptp/gptp.c` إلى فك مرجع (dereference) لرأس gPTP الذي تُرجعه الدالة `GPTP_HDR()`, والانتقال بناءً على قيمة `hdr->message_type` دون التحقق مسبقاً من أن الإطار المستلم يحتوي على ما لا يقل عن حجم بنية `struct gptp_hdr` (34 بايت). إن مُسهل الوصول إلى الرأس `gptp_get_hdr()` مصمم عمداً ليكون دائماً ناجحاً حتى مع المخازن المؤقتة القصيرة؛ حيث يُرجع `pkt->frags->data` ويترك عملية التحقق للمُستدعين. ونتيجة لذلك، أدى الإطار المقصوص (truncated frame) إلى الحصول على مؤشر للرأس يغطي ذاكرة تتجاوز البيانات المستلمة. ولا تعوض الفحوصات الخاصة بنوع الرسالة اللاحقة عن هذا العيب؛ إذ تختزل الدالة `GPTP_VALID_LEN()` الشرط إلى `len > 60` بعد سحب رأس Ethernet، وهو شرط غير صحيح لأي رسالة gPTP ذات حجم ثابت، مما يعني أن دالة `GPTP_CHECK_LEN()` لا ترفض أبداً رسائل SYNC أو FOLLOWUP أو PDELAY_RESP أو SIGNALING المقصوصة.
يتم الوصول إلى هذا العيب من قبل نظير غير مُصادق عليه (unauthenticated peer) على نفس الرابط المرسل لإطار Ethernet بنوع ethertype 0x88F7 نحو عنوان البث المتعدد لبروتوكول PTP في واجهة مُعدة كمنفذ gPTP، مع تفعيل خيار `CONFIG_NET_GPTP`. ونظراً لأن إطارات Ethernet المطابقة للمواصفة تُعبئ (pads) إلى 60 بايتاً، فإن وجود حمولة أقصر من 34 بايتاً يتطلب عادةً رابطاً قادراً على تسليم إطارات بأحجام دون الحد الأدنى؛ مثل برنامج تشغيل native_sim TAP (`drivers/ethernet/eth_native_tap.c`) الذي يمرر أي طول توفره جهاز المضيف، أو ماك (MAC) مُهيأ لقبول الإطارات ذات الأحجام الأصغر من المطلوب.
يتم الاحتفاظ بالحزمة القصيرة (من خلال استدعاء `net_pkt_ref()` إلى المتغيرات `rcvd_sync_ptr` و `rcvd_follow_up_ptr` و `rcvd_pdelay_resp_ptr` أو `rcvd_announce_ptr`) ومعالجتها لاحقاً بواسطة آلات الحالة المعتمدة على الوسيط وغير المعتمدة عليه الموجودة في الملفات الفرعية `subsys/net/l2/ethernet/gptp/gptp_md.c` و `subsys/net/l2/ethernet/gptp/gptp_mi.c`. تقوم هذه الآلات بقراءة عشرات البايتات الإضافية ونسخ بعضها (مثل متجه أولوية الإعلان، وحقل `hdr->port_id`) إلى حالة يتم إرسالها لاحقاً. في ظل مُخصص المخازن المؤقتة الثابت الحجم الافتراضي (`CONFIG_NET_BUF_FIXED_DATA_SIZE`، بقطع حجمها 128 بايت)، تبقى عمليات الوصول داخل القطعة المُخصصة وتكشف عن محتويات مخزن مؤقت معاد تدويره وقديمة (stale)؛ أما في حال استخدام مُخصص المخازن المؤقتة ذات البيانات المتغيرة التجريبي (`CONFIG_NET_BUF_VARIABLE_DATA_SIZE`)، حيث تُخصص القطع على الـ heap بدقة وفقاً لطول الإطار، فإنها تمثل قراءات حقيقية خارج النطاق المسموح به (out-of-bounds reads). لا توجد عملية كتابة ولا أي تأثير على التوفر.
Once again VulDB remains the best source for vulnerability data.