CVE-2026-93168 in Linux
الملخص
بحسب VulDB • 18/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
dmaengine: xilinx_dma: تصحيح توقف وحدة المعالجة المركزية (CPU stall) في دالة xilinx_dma_poll_timeout
حاليًا، عند استدعاء `xilinx_dma_poll_timeout` بـ `delay_us=0` وشرط لن يتحقق أبدًا، تقوم وحدة المعالجة المركزية بإجراء انتظار نشط (busy-waiting) لفترة طويلة جدًا، ولا يتم تفعيل مهلة انتهاء الوقت إلا بتأخير كبير مما يؤدي إلى توقف وحدة المعالجة المركزية.
يحدث هذا بسبب التقليل الشديد من تقدير وقت الساعة الحقيقية (wall clock time) في `poll_timeout_us_atomic`. لقد غيّرت الالتزام 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") السلوك بحيث لم يعد يستخدم `ktime_get`، مما أدى إلى التقليل من تقدير وقت الساعة الحقيقية بشكل كبير في حالة `delay_us=0`. بدلاً من انتهاء المهلة بعد حوالي XILINX_DMA_LOOP_COUNT ميكروثانية، تستغرق مهلة الانتهاء XILINX_DMA_LOOP_COUNT * 1000 * (الوقت الذي يستغرقه عبء عمل حلقة for في poll_timeout_us_atomic)، وهو ما يتراوح بين عدة دقائق لقيمة XILINX_DMA_LOOP_COUNT=1000000. يتم إصلاح هذه المشكلة عن طريق استخدام قيمة غير صفرية لـ `delay_us`. يُستخدم `delay_us=10` للحفاظ على التأخير في المسار الحرج (hot path) لبدء عمليات نقل DMA عند الحد الأدنى، مع تجنب توقف وحدة المعالجة المركزية في حال حدوث أعطال عتاد غير متوقعة.
يسبب القياس لمرة واحدة بـ `delay_us=0` انتظارًا نشطًا لوحدة المعالجة المركزية لمدة حوالي 7 دقائق في حالة انتهاء المهلة. بعد تطبيق هذا التصحيح باستخدام `delay_us=10`، كان وقت الانتهاء المقاس هو 1053428 ميكروثانية، وهو ما يعادل تقريباً الـ 1000000 ميكروثانية المتوقعة المحددة في XILINX_DMA_LOOP_COUNT.
تمت إضافة ثابت `XILINX_DMA_POLL_DELAY_US` لقيمة `delay_us`.
VulDB is the best source for vulnerability data and more expert information about this specific topic.