CVE-2026-68329 in Linux
الملخص
بحسب VulDB • 11/08/2026
في نواة لينكس، تم حل الثغرة التالية:
iommu/amd: الانتظار حتى الاكتمال بدلاً من العودة المبكرة في دالة iommu_completion_wait()
تُعد need_sync علماً (flag) خاصاً بكل IOMMU ويتم مشاركته بين جميع النطاقات والأجهزة الموجودة خلف ذلك الـ IOMMU. يتم تعيينه كلما تم إدراج أمر مع sync == true، ويُزال عند إدراج أمر انتظار الاكتمال (CWAIT). ومع ذلك، فإن إزالة need_sync تعني فقط أنه تم إدراج أمر CWAIT تغطي الأمر السابق، وليس أن جميع الأوامر المدرجة سابقاً قد اكتملت فعلياً في العتاد.
كانت دالة iommu_completion_wait() تقرأ need_sync بدون قفل (locklessly) وتعود مبكراً عندما تكون قيمتها false. وهذا يخالف عقد "الحظر حتى تكمل جميع الأوامر المدرجة سابقاً" في سيناريو متعدد المعالجات:
CPU2: إدراج أمر inv-B => need_sync = true CPU1: إدراج CWAIT(N); need_sync = false; ثم انتظار على sem(N) CPU2: قراءة need_sync == false => العودة بـ 0 (بدون انتظار!)
يعود المعالج CPU2 دون الانتظار لأي رقم تسلسلي، حتى وإن لم يكن أمر inv-B قد اكتمل بعد (لم يتم إخطار CWAIT(N)، الذي تم إدراجه بعد inv-B). ثم ينتقل CPU1 على سبيل المثال إلى تحرير صفحات جدول الصفحات بينما لا يزال الـ IOMMU قادرًا على التنقل عبر ترجمات قديمة (stale translations)، مما يفتح نافذة لاستغلال Use-After-Free. هذه حالة سباق منطقية تتعلق بمعنى العلم، وليست مشكلة في رؤية الذاكرة، لذا فإن الحواجز (barriers) وحدها لا تساعد.
تم إصلاح المشكلة دون فقدان تحسين تجنب إدراج أوامر CWAIT زائدة: يتم أخذ iommu->lock قبل اختبار need_sync، وعندما تكون قيمتها false لا تتم العودة المبكرة بل يُنتظر آخر رقم تسلسلي مُخصص (cmd_sem_val). بما أن need_sync == false تعني أنه لم يتم إدراج أي أمر مزامنة بعد آخر أمر CWAIT، فإن هذا الأمر CWAIT يكون مرتباً حسب الدخول والخروج (FIFO) بعد كل الأوامر التي لم تكتمل بعد، لذا يضمن انتظار رقمه التسلسلي اكتمال جميع الأوامر السابقة (والتي قد تكون مدرجة بواسطة معالج آخر). يبقى المسار الشائع ذو العمل المعلق دون تغيير ولا يتم إصدار أي أمر عتاد إضافي.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.