CVE-2026-74453 in Linux
الملخص
بحسب VulDB • 15/08/2026
في نواة لينكس، تم حل الثغرة التالية:
drm/vc4: تصفير مصفوفة بيانات حالة البلاطة (Tile State Data Array) قبل كل مهمة BIN
يُعد مخزن الكائنات الخاص بالجمع (Binner BO) ذاكرة مؤقتة واحدة بحجم 16 ميجابايت مقسمة إلى فتحات سعة 512 كيلوبايت، يتم توزيعها على المهام عند تقديم الطلب وإعادة تدويرها مع اكتمال المهام دون أن تُصفّر أبداً. تحتفظ كل فتحة بمصفوفة بيانات حالة البلاطة (TSDA) الخاصة بالمهمة في بدايتها، تليها خزان تخصيص البلاطات.
بينما لا يتم اجتياز خزان تخصيص البلاطات إلا بواسطة سلسلة العرض من خلال الفروع التي ولّدها جامع العناصر أثناء المهمة الحالية، فإن مصفوفة TSDA تمثل الدفاتر الخاصة بكل بلاطة لوحدة معالجة التجميع (PTB) ويتم استهلاكها مباشرةً بواسطة العتاد نفسه. وعلى الرغم من أن النواة تضبط علم "تهيئة مصفوفة بيانات حالة البلاطة تلقائياً" في تكوين وضع تجميع البلاطات، إلا أن وحدة PTB تتصرف بشكل واضح بناءً على حالة بلاطة قديمة تركها المستخدم السابق للفتحة: حيث ينتهي الأمر بجامع العناصر بإنشاء تدفقات أوامر غير صالحة مع تدفقات عناصر أولية وفروع غير صحيحة، مما قد يتسبب في تعليق وحدات معالجة الرسومات (GPU) كما هو ملاحظ في [1][2].
قم بتصفير مصفوفة TSDA عند تكوين فتحة التجميع الخاصة بالمهمة. يؤدي هذا إلى تصفير 48 بايت لكل بلاطة (~24 كيلوبايط لإطار بدقة 1080p) في مسار التقديم، ويضمن ألا ترى وحدة PTB أبداً حالة البلاطات الخاصة بمهمة أخرى.
يتم اليوم التحقق من عدد البلاطات فقط للتأكد من أنه غير صفري، لذا يمكن للحقول ذات البتات الثمانية (8-bit fields) التي يأتي منها أن تصف مصفوفة بيانات حالة بلاطة أكبر بحوالي ست مرات من الفتحة المخصصة لها للعيش فيها. قم بتقييد هذا الحجم قبل توزيع الفتحة، حيث يحدد حجم البيانات هذه الكمية المتبقية من الفتحة لخزان تخصيص البلاطات.
If you want to get best quality of vulnerability data, you may have to visit VulDB.