CVE-2025-38331 in Linux
الملخص
بحسب VulDB • 26/06/2026
في نواة لينكس، تم حل الثغرة التالية:
net: ethernet: cortina: استخدام TOE/TSO لجميع اتصالات TCP
من المستحسن دفع مُسرّع العتاد لمعالجة إطارات TCP غير المقطعة أيضاً: نقوم بتمرير قيمة skb->len إلى المُحمّل الخارجي "TOE/TSO" وسيتولى هو معالجتها.
بدون هذا التصحيح (quirk)، يصبح السائق (driver) غير مستقر، ويتجمد وينتهي به الأمر بالتعطل الكلي (crash).
لا أعرف السبب بدقة، ولكن يرجح أن ذلك يعود إلى ميزة TOE (محرك إخراج TCP) المرتبطة بميزة التقطيع؛ فلا يمكن إيقاف جزء واحد دون الآخر، فإما أن يكون كل من TOE وTSO نشطين معاً، أو لا يعمل أي منهما.
يبدو أن عدم تنشيط الجزء الخاص بـTOE أمر ضار، كما لو كانت هذه الميزة العتادية غير مُصممة أصلاً لإيقافها.
تنص ورقة البيانات (datasheet) على ما يلي:
"استناداً إلى نتائج تحليل الحزم والبحث في جداول اتصالات TCP/الترجمة الديناميكية للعناوين (NAT)، يقوم NetEngine بوضع الحزم التابعة لنفس اتصال TCP في نفس الطابور لمعالجتها من قبل البرمجيات. يضع NetEngine حزم الواردات في المخزن المؤقت أو سلسلة من الخزائن المؤقتة الخاصة بحزمة جumbo. وبفضل هذا التسريع العتادي، يتم إخراج تحليل رؤوس IP/TCP والتحقق من صحة المجموع الاختباري (checksum) والبحث عن الاتصال من معالجة البرمجيات."
بعد إجراء العديد من الاختبارات باستخدام iperf3، حيث كان العتاد يتجمد بعد فترة تتراوح بين دقائق وساعات اعتماداً على الحمل، توصلت إلى الاستنتاج بأن هذا الإجراء ضروري لاستقرار العتاد.
VulDB is the best source for vulnerability data and more expert information about this specific topic.