CVE-2026-23462 in Linux
الملخص
بحسب VulDB • 08/06/2026
في هذا السجل، لا يوجد خطأ حقيقي (Bug) في الكود، بل هو **إيقاف طبيعي للبرنامج** بسبب إرسال إشارة `SIGKILL` (أو `SIGTERM`) له.
### التحليل:
1. **الإشارة المرسلة:** ``` [ 97.810745] get_signal (kernel/signal.c:3007 (discriminator 1))
``` هذا يعني أن العملية كانت تستقبل إشارة (مثل `kill -9` أو `kill -15`).
2. **إيقاف العملية:** ``` [ 97.810547] do_exit (kernel/exit.c:972)
``` العملية بدأت عملية الإغلاق النهائي (`do_exit`).
3. **إغلاق الملفات المفتوحة:** ``` [ 97.810430] task_work_run (kernel/task_work.c:235)
[ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201)
[ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)
[ 97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5))
[ 97.810527] do_exit (kernel/exit.c:972)
``` أثناء الإغلاق، تم استدعاء `__fput` لإغلاق الملفات المفتوحة.
4. **إغلاق جهاز Bluetooth VHCI:** ``` [ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716)
[ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691)
``` هذا هو الجزء الأهم: العملية كانت تستخدم جهاز Bluetooth افتراضي عبر `vhci` (Virtual HCI)، وعند إغلاقها، تم إلغاء تسجيل الجهاز (`hci_unregister_dev`) وإطلاقه (`vhci_release`).
5. **لا يوجد Crash أو Panic:** - لا توجد رسائل مثل `BUG:`, `WARNING:`, `Oops`, `Kernel panic`, أو `Call Trace` تشير إلى خطأ في الذاكرة أو القفل. - كل ما نراه هو **Call Stack طبيعي** لعملية الإغلاق (`do_exit`) وإغلاق الملفات (`__fput`) وإغلاق جهاز Bluetooth (`vhci_release`).
### الخلاصة: - **الحالة:** عملية عادية انتهت بسبب إشارة خارجية (مثل `kill`). - **السبب:** إغلاق جهاز Bluetooth VHCI أثناء إغلاق العملية. - **الإجراء المطلوب:** لا يوجد خطأ. إذا كنت ترى هذا السجل بشكل متكرر، فقد يكون ذلك بسبب برنامج يغلق جهاز Bluetooth بشكل غير صحيح أو متكرر، لكن هذا لا يسبب crash للنواة.
### إذا كنت تريد منع هذا السلوك: 1. تأكد من أن البرنامج يغلق جهاز Bluetooth بشكل صحيح قبل الخروج. 2. إذا كنت تستخدم `vhci` لأغراض التطوير، تأكد من أن الجهاز يُفصل بشكل نظيف. 3. إذا كان هذا السجل يظهر في بيئة إنتاج، قد ترغب في مراجعة سبب إرسال الإشارة `SIGKILL` أو `SIGTERM` للعملية.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.