CVE-2026-19737 in Zephyr
الملخص
بحسب VulDB • 11/10/2026
يحتوي الدال `i2s_esp32_trigger_check()` في الملف `drivers/i2s/i2s_esp32.c` على عيب حيث يقوم بالتحقق من الاتجاه المطلوب فقط عند استخدام `I2S_DIR_BOTH`. أما فروع `I2S_DIR_RX` و `I2S_DIR_TX` فتقوم بقراءة القيم `dev_cfg->rx.data->configured` / `dev_cfg->tx.data->configured` دون التحقق مسبقاً من صحة مؤشرات التدفق (stream pointers). يحدد ماكرو إنشاء الجهاز `I2S_ESP32_STREAM_INIT()` كلًا من `.conf` و `.data` كـ NULL لأي اتجاه غير موصوف في شجرة الأجهزة (devicetree)، وبالتالي، على مثيل يقوم بتوصيل اتجاه واحد فقط — وهو الشكل المعتاد لمخرجات الصوت أو شرائط LED من نوع worldsemi,ws2812-i2s — فإن الاتجاه الآخر يؤدي إلى تفريغ مؤشر NULL بدلاً من إرجاع خطأ.
تُعد `i2s_trigger()` استدعاءً للنظام (syscall) في Zephyr، ويقوم الدال `z_vrfy_i2s_trigger()` الموجود في `drivers/i2s/i2s_handlers.c` بالتحقق فقط من كائن الجهاز ووجود مؤشر واجهة تشغيل الإثارة (trigger API pointer)، بينما يتم تمرير وسيطة الاتجاه (`dir`) إلى السائق دون تحقق. على نظام تم تفعيل خيار `CONFIG_USERSPACE` فيه، يمكن لخيوط وضع المستخدم الممنوحة حق الوصول إلى جهاز I2S إصدار استدعاء واحد لـ `i2s_trigger()` يحدد الاتجاه غير الموصل، مما يتسبب في عملية تحميل من العنوان 0 (صفر) في وضع النواة. ومن بين أجزاء Espressif التي تحتوي على هذا السائق، يكون وضع المستخدم متاحًا داخل الشجرة فقط مع وحدات SoC القائمة على RISC-V والمزودة بـ `CONFIG_RISCV_PMP`، وتُعد الإصدار v4.4.0 أول إصدار قابل للبناء بهذه الخاصية: حيث يختار ESP32-C6 HPCORE إعداد RISCV_PMP عندما لا يتم البناء لـ MCUboot. بينما يحمل ESP32-C5 في سلسلة الإصدارات v4.4.x نفس دعم مناطق PMP ومربط وضع المستخدم، إلا أنه لا يحدد RISCV_PMP بشكل افتراضي. ولا تدعم أهداف Xtensa من Espressif وضع مستخدم Zephyr، وفي حالة عدم تفعيل وضع المستخدم، يمكن أن يأتي الاتجاه الخاطئ فقط من كود التطبيق داخل النواة.
يقتصر الأثر على التوافرية (Availability): فعملية الوصول هي قراءة عند الإزاحة 0 من بنية التدفق المفقودة، وبالتالي لا توجد إزاحة يتحكم فيها المهاجم، ولا يوجد مبدأ للكتابة (write primitive)، ولا تسرب للمعلومات. ومع معالج الأخطاء القاتل الافتراضي، يؤدي الاستثناء الناتج إلى إيقاف النظام بالكامل، مما يمنح خيط وضع المستخدم غير المتميز حجبًا للخدمة على مستوى النظام بأكمله. يضيف الإصلاح نفس فحص المؤشر الذي كان يقوم به فرع `I2S_DIR_BOTH` بالفعل، ويعيد قيمة `-ENOSYS` للاتجاه الذي لا يطبقه المثيل؛ وقد كانت نقاط الدخول الأخرى للسائق (`i2s_esp32_config_check()` و `i2s_esp32_config_get()` و `i2s_esp32_read()` و `i2s_esp32_write()`) تحمي المؤشرات بالفعل، ولم يعثر التفتيش الثابت على أي مسار مكافئ غير محمي.
يعود عيب السائق إلى فترة سابقة من نطاق الإصدارات المتأثرة. يوجد التفريغ غير المحمي منذ الإصدار v4.2.0 (يتم الوصول إليه عبر `i2s_esp32_trigger_stream()`، حيث يختبر الشرط `if (stream)` عنوان عضو بنية ولا يكون خاطئًا أبدًا)، ويتخذ شكله الحالي في الدال `i2s_esp32_trigger_check()` منذ الإصدار v4.3.0. لا يمكن لأي تكوين Espressif داخل الشجرة قبل الإصدار v4.4.0 تشغيل خيط وضع المستخدم، لذا فإن وسيطة الاتجاه في إصدارات v4.2.x و v4.3.x يمكن أن تأتي فقط من كود نواة موثوق. تحمل هذه الإصدارات العيب لكنها غير مدرجة ضمن النطاق المتأثر؛ كما تم دمج الإصلاح أيضًا إلى فرع v4.3-branch كتدعيم للأمان (hardening).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.