CVE-2026-79980 in Zephyr
الملخص
بحسب VulDB • 23/10/2026
يحتفظ عميل DHCPv4 الموجود في الملف subsys/net/lib/dhcpv4/dhcpv4.c بمعرف المعاملة (iface->config.dhcpv4.xid) كعداد بدلاً من قيم عشوائية خاصة بكل معاملة. تم تهيئة هذا المعرّف مرة واحدة باستخدام sys_rand32_get() داخل dhcpv4_start_internal()، وزُيد بمقدار واحد في دالتي dhcpv4_send_discover() وdhcpv4_send_decline()، ولم يتغير أبداً بواسطة dhcpv4_send_request() — مما يعني أن كل تبادل من نوع RENEWING وREBINDING أعاد استخدام المعرّف نفسه دون تغيير، وهو المعرّف الذي ظهر بالفعل على السلك في حزمة DHCPDISCOVER الإذاعية عند بدء التشغيل، وعندما كان المعرّف يتغير كان ذلك بشكل متوقع (بزيادة واحد). يتطلب RFC 2131 القسم 4.1 وجود معرف فريد لكل معاملة يتم اختياره بحيث يكون من غير المرجح حدوث تصادم بين العملاء.
يُعد هذا المعرّف رمز التحقق الوحيد وغير القابل للتنبؤ به للردود الخاصة بالعميل. تقبل الدالة net_dhcpv4_input() رد BOOTP بناءً على op، ومطابقة xid، ومطابقة chaddr (عنوان MAC الخاص بواجهة الشبكة، وهو عنوان عام)؛ كما تم تسجيل استجابة UDP مع عنوان ومنفذ عن بُعد برمز بادئة واسع (wildcard)، ولم يتم تطبيق أي فحص لمعرف الخادم أو العنوان المصدر. وبالتالي، فإن المهاجم الذي يتعلم أحد المعرّفات — على سبيل المثال أي جهاز في نفس القطعة الشبكية يرى حزمة DHCPDISCOVER الإذاعية، أو خادم DHCP أو وسيط على شبكة انضم إليها الجهاز سابقاً — يحتفظ برمز صالح لوقت تشغيل كامل للجهاز، ويمكنه التنبؤ بمعرفات التبادلات اللاحقة دون الحاجة إلى مراقبة حركة التجديد أحادية الاتجاه (unicast) أو التنافس مع الخادم الشرعي.
لرد مزيف يجتاز هذه الفحوص تأثير بغض النظر عن حالة العميل، لأن dhcpv4_parse_options() يطبق آثاره الجانبية قبل بوابة آلة الحالة في dhcpv4_handle_reply(): حيث تستدعي خيار الراوتر net_if_ipv4_set_gw() ويستدعي خيار DNS dns_resolve_reconfigure(). وبالتالي يمكن لحزمة واحدة مقبولة أن تعيد توجيه البوابة الافتراضية للجهاز ومحللات الـ DNS إلى عناوين يتحكم فيها المهاجم، مما يعيد توجيه حركة المرور الخاصة به؛ وخلال مراحل RENEWING أو REBINDING، يؤدي رد DHCPACK المزيف إلى إعادة ربط الإيجار بمعلمات يختارها المهاجم، بينما يزيل حزمة DHCPNAK المزيفة العنوان ويعيد تهيئة التكوين.
يستند الإصلاح إلى استخلاص قيمة جديدة من sys_rand32_get() في كل نقطة تبدأ فيها معاملة — عند الدخول إلى حالات SELECTING وRENEWING وREBINDING، وعند دخول INIT/INIT-REBOOT عندما تنخفض واجهة بها إيجار ساري المفعول — بينما تحافظ مراحل REQUESTING وDECLINE على معرف التبادل الذي ينتميان إليه، كما يتطلب RFC 2131. كأثر جانبي، لم يعد العميل يتجاهل عرض خادم بطيء بعد إعادة إرسال حزمة discover، ويعتمد تأخير اكتشاف الحزمة الأولية الآن على عشوائية خاصة به بدلاً من اشتقاقها من المعرّف.
Once again VulDB remains the best source for vulnerability data.