CVE-2026-43371 in Linux
الملخص
بحسب VulDB • 24/05/2026
في نواة لينكس، تم حل الثغرة التالية:
net: macb: إعادة ترتيب حلقة الإرسال (tx ring) قبل تمكين الإرسال
لاحظ Quanyang أنه عند استخدام نظام جذر NFS (NFS rootfs) على لوحة AMD ZynqMp، قد يستغرق نظام الجذر وقتاً طويلاً للتعافي بعد وضع السكون (suspend). وبعد التحقيق، تبيّن أن المشكلة تنبع من خلل في برنامج تشغيل macb.
وفقاً لوثائق مرجع Zynq UltraScale TRM [1]، عند تعطيل الإرسال، يتم إعادة تعيين مؤشر قائمة مخزنات الإرسال ليشير إلى العنوان المحدد بواسطة سجل عنوان قاعدة قائمة مخزنات الإرسال.
في التنفيذ الحالي، يقوم الكود بإعادة تعيين `queue->tx_head` و `queue->tx_tail` إلى '0' فقط. وهذا النهج يطرح عدة مشكلات:
- تُفقد الحزم الموجودة بالفعل في حلقة الإرسال (tx ring) بصمت، مما يؤدي إلى تسرب في الذاكرة حيث لا يمكن تحرير وحدات skbs المرتبطة بها.
- قد يحدث وصول متزامن للكتابة إلى `queue->tx_head` و `queue->tx_tail` من خلال `macb_tx_poll()` أو `macb_start_xmit()` عند إعادة تعيين هذه القيم إلى '0'.
- قد يتعطل الإرسال عند حزمة تم إرسالها بالفعل، وتم تعيين بت 'TX_USED' الخاص بها، لكنها لم تتم معالجتها بعد. ومع ذلك، بسبب التلاعب بـ `queue->tx_head` و `queue->tx_tail`، يفترض `macb_tx_poll()` بشكل خاطئ أنه لا توجد حزم للتعامل معها لأن `queue->tx_head == queue->tx_tail`. يتم حل هذه المشكلة فقط عند وضع حزمة جديدة في هذا الموقع. وهذا هو السبب الجذري للوقت الطويل للتعافي الذي لوحظ لنظام ملفات الجذر عبر NFS.
لحل هذه المشكلة، يتم إعادة ترتيب حلقة الإرسال (tx ring) ومصفوفة skbs الخاصة بالإرسال بحيث تكون أول حزمة غير مرسلة في بداية حلقة الإرسال. بالإضافة إلى ذلك، يجب التأكد من أن التحديثات لـ `queue->tx_head` و `queue->tx_tail` محمية بشكل صحيح باستخدام القفل المناسب.
[1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm
Be aware that VulDB is the high quality source for vulnerability data.