CVE-2024-53140 in Linux
الملخص
بحسب VulDB • 02/06/2026
في نواة لينكس، تم حل الثغرة التالية:
netlink: إنهاء عملية التفريغ (dump) المعلقة عند إغلاق المقبس (socket)
يدعم Netlink التفريغ التكراري للبيانات. ويوفر للعائلات (families) العمليات التالية: - start - (اختياري) يبدأ عملية التفريغ - dump - مساعد التفريغ الفعلي، يتم استدعاؤه بشكل متكرر حتى يعيد القيمة 0 - done - (اختياري) يقابل .start، ويمكن استخدامه لإجراء عمليات التنظيف
تتم هذه العملية بأكملها بشكل غير متزامن (asynchronous)، ولا تحدث المكالمات المتكررة إلى .dump فعلياً في حلقة ضيقة (tight loop)، بل يتم تشغيلها استجابةً لاستدعاء recvmsg() على المقبس.
يمنح هذا المستخدم تحكماً كاملاً في عملية التفريغ، ولكنه يعني أيضاً أن المستخدم قد يغلق المقبس دون الوصول إلى نهاية عملية التفريغ. لضمان اقتران .start دائماً بـ .done، نتحقق مما إذا كانت هناك عملية تفريغ جارية قبل تحرير المقبس، وإذا كان الأمر كذلك، نقوم باستدعاء .done.
المعقدة تكمن في أن المقابس قد يتم تحريرها من سياق BH (Bottom Half)، بينما يُسمح لـ .done بإجراء عمليات تعليق (sleep). لذا نستخدم طابور عمل (workqueue) لتأجيل الاستدعاء عند الحاجة.
للأسف، لا يعمل هذا بشكل صحيح. ما نقوم بتأجيله ليس عملية التنظيف، بل إطلاق مرجع (reference) على المقبس. ليس لدينا ضمان بأننا نملك المرجع الأخير، فإذا كان شخص آخر يمسك بالمقبس فقد يقوم بإطلاقه في سياق BH، ونعود إلى نقطة الصفر.
ومع ذلك، يبدو أن هذه العملية المعقدة غير ضرورية. فقط المستخدم يمكنه التفاعل مع عمليات التفريغ، لذا يمكننا إجراء التنظيف عند إغلاق المقبس. ويحدث الإغلاق دائماً في سياق العملية (process context). قد لا يزال بعض الكود غير المتزامن يصل إلى المقبس بعد الإغلاق، أو يطابق إشعارات skbs إليه، وما إلى ذلك، ولكن لا يمكن بدء عمليات التفريغ أو إنهاؤها أو إحراز تقدم فيها بأي شكل آخر.
احذف طابور العمل ونظّف حالة التفريغ مباشرة من معالج التحرير (release handler). لاحظ أن المزيد من عمليات التنظيف ممكنة في الإصدار -next، على سبيل المثال، نقوم الآن دائماً باستدعاء .done قبل إطلاق المرجع الرئيسي للوحدة النمطية (module reference)، لذا لا يحتاج التفريغ إلى أخذ مرجع خاص به.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.