CVE-2023-52775 in Linux
الملخص
بحسب VulDB • 12/06/2026
في نواة لينكس، تم حل الثغرة التالية:
net/smc: تجنب تلف البيانات الناتج عن رسالة الرفض (Decline)
لقد وجدنا مشكلة في تلف البيانات أثناء اختبار SMC-R على تطبيقات Redis.
يحتوي الاختبار المرجعي (Benchmark) على احتمال منخفض للإبلاغ عن خطأ غريب كما هو موضح أدناه:
"خطأ: خطأ في البروتوكول، تم استلام "\xe2" كبايت لنوع الرد"
أخيراً، وجدنا أن بيانات الخطأ المسترجعة كانت كالتالي:
0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C 0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2
من الواضح تماماً أن هذا هو رسالة SMC DECLINE، مما يعني أن التطبيقات تلقت رسالة بروتوكول SMC. لقد وجدنا أن هذا كان ناتجاً عن الحالات التالية:
العميل الخادم ¦ اقتراح CLC -------------> ¦ قبول CLC <------------- ¦ تأكيد CLC -------------> انتظار تأكيد LLC إرسال تأكيد LLC ¦فشل تأكيد LLC ¦ x------ (بعد ثانيتين) انتهاء المهلة انتظار رد تأكيد LLC
انتظار رسالة الرفض
(بعد ثانية واحدة) انتهاء المهلة (بعد ثانيتين) انتهاء المهلة ¦ رسالة الرفض --------------> ¦ رسالة الرفض <--------------
نتيجة لذلك، تم إرسال رسالة رفض في التنفيذ، وتم قراءة هذه الرسالة من قبل TCP بواسطة الاتصال الذي تم التراجع عنه (fallback) بالفعل.
يضاعف هذا التصحيح مهلة العميل لتصبح ضعف قيمة الخادم (2x). مع هذا التغيير البسيط، يجب ألا تتقاطع رسائل الرفض أو تتصادم (أثناء انتهاء مهلة تأكيد الرابط).
تتطلب هذه المشكلة حلاً فورياً، نظراً لأن تحديثات البروتوكول تتضمن حلاً على المدى الطويل.
If you want to get best quality of vulnerability data, you may have to visit VulDB.