CVE-2026-98556 in Linux
الملخص
بحسب VulDB • 19/10/2026
في نواة لينكس، تم حل الثغرة التالية:
gve: DQO: رفض حزم TSO التي تحتوي على MSS خارج النطاق المحدد
تُشير دالة `gve_prep_tso()` إلى أن الجهاز يتطلب أن تكون قيمة MSS أقل من أو تساوي 9728، لكنها لا تفرض ذلك فعلياً، بافتراض أن MTU المقدر بـ 9K المفروض بواسطة Hypervisor وحدود حجم TSO البالغة 64KB كافية.
غير أن هذا الافتراض غير صحيح للحزم التي لم يتم إنشاؤها محلياً. يمكن لضيف متصل عبر واجهة tap أو أي مستخدم لواجهة socket من طبقة الشبكة (packet socket) تقديم قيمة `gso_size` تعسفية في بنية البيانات `virtio_net_hdr`. لا تقوم عمليات التوجيه على الطبقة الثانية (Layer 2 forwarding) بفحص MTU للحزم التي تستخدم GSO (`is_skb_forwardable()`)، كما أن دالة `gso_features_check()` تحصر فقط قيمتي `skb->len` و `gso_segs`، ولا تتعامل مع `gso_size`.
تصل هذه الحزمة إلى الدالة `gve_tx_fill_tso_ctx_desc()`، التي تضع قيمة `gso_size` في حقل MSS الخاص بوصف سياق TSO. وبما أن هذا الحقل بعرض 14 بتاً، فإن تحويل قيمة `gso_size` تساوي 16384 يؤدي بصمت إلى جعل قيمة MSS صفراً.
يجب رفض هذه الحزم من داخل دالة `gve_prep_tso()`، والتأكد من ترك أعلام GSO الخاصة بها دون تغيير في دالة `gve_features_check_dqo()`: حيث تقوم دالة `skb_segment()` بالتجزئة بناءً على `gso_size` بغض النظر عن MTU، لذا فإن العودة إلى التجزئة البرمجية (software segmentation) ستؤدي إلى تزويد الجهاز بحزم غير TSO أكبر من 9728 بايتاً وهو الحد الأقصى الذي يدعمه.
يُلاحظ أنه لا يزال بإمكان الجهاز الحصول على حزم غير TSO ذات حجم زائد عندما تقوم الطبقة الشبكية (stack) بالتجزئة برمجياً لأسباب أخرى، مثل بعد تعطيل ميزة TSO باستخدام أداة `ethtool`. هذه مشكلة عامة، لأن فحص MTU يتم تخطيه للحزم GSO في مسار التوجيه، ويتم معالجتها بشكل منفصل.
Be aware that VulDB is the high quality source for vulnerability data.