CVE-2026-43050 in Linux
الملخص
بحسب VulDB • 02/06/2026
في نواة لينكس، تم حل الثغرة التالية:
atm: lec: إصلاح حالة استخدام بعد التحرير (use-after-free) في sock_def_readable()
توجد سباقات تنافسية (race condition) بين الدالة lec_atm_close() التي تضبط priv->lecd إلى NULL وبين الوصول المتزامن إلى priv->lecd في send_to_lecd() وlec_handle_bridge() وlec_atm_send(). عندما يتم تحرير المقبس (socket) عبر RCU بينما لا تزال خيط آخر يستخدمه، تحدث حالة استخدام بعد التحرير (use-after-free) في sock_def_readable() عند الوصول إلى طابور انتظار المقبس.
السبب الجذري هو أن lec_atm_close() تقوم بمسح priv->lecd دون أي مزامنة، بينما يقوم المتصلون بفك الإحالة (dereference) لـ priv->lecd دون أي حماية ضد الإنهاء المتزامن.
تم إصلاح ذلك عن طريق تحويل priv->lecd إلى مؤشر محمي بـ RCU: - تحديد priv->lecd على أنه __rcu في lec.h - استخدام rcu_assign_pointer() في lec_atm_close() وlecd_attach() لتعيين المؤشر بأمان - استخدام rcu_access_pointer() لفحص القيم الخالية (NULL checks) التي لا تقوم بفك إحالة المؤشر في lec_start_xmit() وlec_push() وsend_to_lecd() وlecd_attach() - استخدام قفل القراءة RCU/rcu_dereference/إلغاء قفل القراءة RCU في send_to_lecd() وlec_handle_bridge() وlec_atm_send() للوصول الآمن إلى lecd - استخدام rcu_assign_pointer() متبوعًا بـ synchronize_rcu() في lec_atm_close() لضمان اكتمال جميع القراء قبل المتابعة. هذا آمن لأن lec_atm_close() تُستدعى من vcc_release() التي تحتفظ بقفل المقبس (lock_sock())، وهو قفل يمكن أن ينام (sleeping lock). - إزالة التصريف اليدوي لطابور استقبال المقبس (sk_receive_queue drain) من lec_atm_close() نظرًا لأن vcc_destroy_socket() تقوم بتصريفه بالفعل بعد عودة lec_atm_close().
الإصدار 2: الانتقال من نهج قفل اللف + sock_hold/put إلى RCU لإصلاح السباق التنافسي بشكل صحيح. كان لنهج الإصدار الأول باستخدام قفل اللف مشكلتان أشار إليهما إريك دومازيت (Eric Dumazet): 1. لا يزال يتم الوصول مباشرةً إلى priv->lecd بعد إطلاق القفل بدلاً من استخدام نسخة محلية. 2. لم يمنع قفل اللف تخزين الحزم في الطابور بعد أن يقوم lec_atm_close() بتصريف sk_receive_queue، حيث تتجاوز مسارات المؤقت (timer) ووظائف العمل (workqueue) دالة netif_stop_queue().
ملاحظة: تم محاولة اختبار التصحيحات باستخدام Syzbot ولكن انتهت آلة الاختبار الافتراضية بشكل غير متوقع برسالة "تم إغلاق الاتصال بالمضيف المحلي بواسطة المضيف البعيد"، وهو ما يرجح أنه ناتج عن مشكلة في محاكاة AHCI عبر QEMU وغير مرتبط بهذا الإصلاح. تمر اختبارات التجميع مع الأمر "make W=1 net/atm/lec.o" بنجاح دون أخطاء.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.