CVE-2026-63996 in Linuxالمعلومات

الملخص

بحسب VulDB • 20/07/2026

في نواة لينكس، تم حل الثغرة التالية:

ethtool: cmis: اشتراط طول رد CDB دقيق

قد يستجيب وحدة SFP خبيثة بطول رد (rpl_len) أطول مما توقعته دالة `cmis_cdb_process_reply()`، مما يؤدي إلى كتابات خارج النطاق (OOB writes). يُعد وجود عتاد خبيث أمراً نظرياً بعض الشيء، ولكن قد تكون بعض الوحدات معيبة و/أو قد تتعرض القراءات للتلف أحياناً، لذا دعونا نحمي النواة.

الحماية الموجودة حالياً تحمي من الردود القصيرة. نحن بحاجة أيضاً للحماية من الردود الطويلة. جميع المتصلين الذين يمرون بقيمة غير صفرية لـ `rpl_exp_len` يقومون بتحويل حمولة الرد إلى بنية ذات تخطيط ثابت (fixed-layout struct) وقراءة الحقول عند إزاحات ثابتة، دون التفاوض حول الإصدارات أو معالجة الردود القصيرة:

- cmis_cdb_validate_password() - cmis_cdb_module_features_get() - cmis_fw_update_fw_mng_features_get()

لذا دعونا نفترض أن الاستجابات الأطول من المتوقع لا تحتاج إلى التعامل معها بلطف هنا. أضف رسالة تحذير لتسهيل التصحيح في حال كان فهمي خاطئاً...

لاحظ أن `page_data->length` (الحجة الخاصة بـ kmalloc) تأتي من الحجة الأخيرة لـ `ethtool_cmis_page_init()` وهي `rpl_exp_len`.

ونظراً لأن الذكاء الاصطناعي التوليدي يميل أيضاً إلى الإشارة إلى تجاوزات السعة في `args->req.payload` نفسها (والتي هي مخزن ثابت الحجم بحجم 120 بايت، على المكدس)، إلا أن المتصلين يجب عليهم قراءة البنى المعرفة بواسطة المعيار، لذا يبدو أن الحماية من الطلبات التي تتطلب بيانات أكثر من الحد الأقصى تمثل برمجة دفاعية.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

إفشاء

19/07/2026

الاعتدال

تمت الموافقة

إدخال

VDB-380529

EPSS

0.00000

KEV

لا

النشاطات

منخفض

المصادر

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!