CVE-2026-64405 in Linux
الملخص
بحسب VulDB • 26/07/2026
في نواة لينكس، تم حل الثغرة التالية:
بلوتوث: hci_conn: إصلاح تجاوز المؤشر الفارغ (null ptr deref) في دالة `hci_abort_conn()`
كانت الدالة `hci_abort_conn()` تقرأ قيمة `hci_skb_event(hdev->sent_cmd)` عندما يكون اتصال قيد الانتظار، ولكن يمكن أن تكون القيمة `hdev->sent_cmd` فارغة (NULL) بينما لا تزال حالة الطلب `HCI_REQ_PEND`. هذا يؤدي إلى تجاوز لمؤشر فارغ وخطأ في حماية النظام العامة من مسار الاستقبال الخاص بـ `hci_rx_work()`.
وبدلاً من فحص قيمة `hdev->sent_cmd`، يتم تتبع أمر إنشاء الاتصال قيد التنفيذ باستخدام علم جديد خاص بكل اتصال وهو `HCI_CONN_CREATE`، وتوجيه جميع عمليات الإلغاء عبر دالة `hci_cancel_connect_sync()`، التي تقوم بتوزيع المهمة إلى وظيفة إلغاء مخصصة لكل نوع. يكون أمر الإنشاء في حالة واحدة فقط من حالتين: إما لا يزال في طابور الانتظار، أو قيد التنفيذ. تحتفظ وظيفة القفل بـ `cmd_sync_work_lock` طوال عملية اتخاذ القرار بالكامل؛ حيث يأخذ العامل هذا القفل لإزالة كل عنصر من الطابور، لذا فإن وجود القفل يمنع بدء تشغيل أمر كان في الطابور ومنع اكتمال أمر قيد التنفيذ والسماح للأمر التالي بأن يصبح معلقاً. يحافظ ذلك على اختبار العلم ودالة `hci_cmd_sync_cancel()` كعملية ذرية بالنسبة للعامل، بحيث يتم ببساطة إزالة الأمر من طابور الانتظار، وإلغاء أمر قيد التنفيذ يخص هذا الاتصال دون خطر إلغاء أمر غير ذي صلة أصبح معلقاً في هذه الأثناء. يستخدم CIS آلية علم مماثلة عبر `HCI_CONN_CREATE_CIS` ولكن لا يمكن إزالته من الطابور لكل اتصال على حدة.
تقوم الدالتان `hci_acl_create_conn_sync()` و `hci_le_create_conn_sync()` بتصفير العلم `HCI_CONN_CREATE` بعد اكتمال أمر الإنشاء، لكن معالج حالة الأمر قد يقوم بإزالة الكائن `conn` عبر دالة `hci_conn_del()` (على سبيل المثال عندما يرفض المتحكم الاتصال) بينما لا يزال العامل محجوزاً بانتظار حدث اكتمال الاتصال. يتم الاحتفاظ بمرجع على الكائن `conn` طوال فترة أمر الإنشاء بحيث يمكن تصفير العلم دون حدوث حالة استخدام بعد الإزالة (use-after-free).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.