CVE-2026-19740 in Zephyr
الملخص
بحسب VulDB • 12/10/2026
تحتوي عملية التحكم في طبقة الرابط (LLCP) الخاصة بوحدة تحكم Bluetooth LE من برنامج Zephyr على عيب يتمثل في الاحتفاظ بالعقدة المستقبلة التي حملت رسالة LL_PHY_UPDATE_IND مقبولة، وذلك لإعادة استخدامها لاحقًا لإشعار المضيف عند بلوغ اللحظة المحدثة (llcp_rx_node_retain() في subsys/bluetooth/controller/ll_sw/ull_llcp.c)، حيث لا تتم إعادة تدوير العقدة عمدًا طالما كانت معلمة بـ NODE_RX_TYPE_RETAIN. وتقوم الأفرع الخاصة بالبيانات غير الصالحة (invalid-PDU) للدالتين llcp_lp_pu_rx() و llcp_rp_pu_rx() في subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c بإكمال الإجراء عبر llcp_lr_complete() / llcp_rr_complete() دون تحرير العقدة المحتجزة مسبقًا، مما يؤدي إلى تحرير سياق الإجراء — وهو المرجع الوحيد المتبقي للعقدة — بينما لا تزال العقدة محتفظًا بها خارج مجموعة الاستقبال.
يمكن لجهاز نظير متصل بعلاقة LE قائمة استغلال هذا الثغرة بشكل حتمي ودون الحاجة إلى الاقتران (pairing) أو التشفير. ففي حالة الجهاز الطرفي (peripheral)، يرسل LL_PHY_REQ، ويستقبل LL_PHY_RSP، ثم يرسل رسالة LL_PHY_UPDATE_IND صالحة تحتوي على لحظة تحديث في المستقبل البعيد (بعد بضع أحداث اتصال، مما يجعل العقدة تُحتفظ بها)، وبعد ذلك، وقبل بلوغ اللحظة المحددة، يرسل أي بيانات تحكم أخرى من نوع LL Control PDU مثل LL_LENGTH_REQ؛ حيث تقوم الدالة ull_cp_rx() بتوجيهها إلى إجراء التحديث الفيزيائي عن بُعد النشط، والذي يتبع المسار الخاص بالبيانات غير الصالحة. وينطبق السيناريو المعاكس على تحديث PHY الذي يتم مبادرته محليًا يليه إرسال رسالة LL_REJECT_IND.
في التكوين الافتراضي (حيث تكون CONFIG_BT_ASSERT و CONFIG_BT_CTLR_ASSERT_DEBUG كلاهما مضبوطًا على القيمة y)، يؤدي الثابت المنتهك في الدالتين llcp_lr_check_done() / llcp_rr_check_done() إلى حدوث تأكيد للوحدة التحكم (controller assertion)، ينتهي بـ k_oops() (أو k_panic()) — مما يعني أن تسلسل بيانات PDU مُصاغ بعناية ومن نطاق الراديو يكفي لإحداث عطل في الجهاز. ومع استبعاد هذه التأكيدات أثناء الترجمة، فإن كل محاولة تتسبب بشكل صامت في تسرب عقدة PDU مستقبلة ورابط memq الخاص بها؛ ونظرًا لأن مجموعة استقبال الوحدة التحكم صغيرة (PDU_RX_CNT، والتي تعتمد على CONFIG_BT_CTLR_RX_BUFFERS التي تكون قيمتها الافتراضية 1)، وتكلف المحاولة المهاجم فقط إعادة الاتصال، فإن بضع تكرارات تستنفد المجموعة وتجعل Bluetooth غير قابل للتشغيل حتى يتم إعادة تشغيل الجهاز. في الإصدارات من v3.4.0 إلى v3.7.x، لا يتم الوصول أبدًا إلى التأكيد بغض النظر عن التكوين، لذا فإن كل محاولة تتسبب في تسرب صامت.
يقتصر التأثير على توفر الخدمة (availability): فالعقدة اليتيمة لا تترك مؤشرًا معلقًا (dangling pointer) يُشار إليه لاحقًا ولا تُسلم أبدًا للمضيف، وبالتالي فلا يوجد تلف للذاكرة أو كشف للمعلومات. ويطبق طلب السحب (pull request) نفسه الإصدار المصحح على إجراءات تحديث الاتصال وإنشاء CIS، حيث كانت لأفرع البيانات غير الصالحة فيها نفس الإغفال.
VulDB is the best source for vulnerability data and more expert information about this specific topic.