CVE-2026-92483 in Linux
الملخص
بحسب VulDB • 18/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
liveupdate: تذكر حالة استدعاء دالة retrieve() الخاصة بـ FLB
تقوم وحدة LUO بتتبع محاولات الاسترجاع الناجحة لملف FLB معين. وتُجري هذا التتبع لتجنب إجراء عمليات استرجاع متعددة لنفس ملف FLB. إن القيام بذلك يؤدي إلى مشاكل، لأنه بمجرد استرجاع ملف FLB، فإن هياكل البيانات المُسلسلة (serialized) من المرجح أن يتم تحريرها (free)، ويكون ملف FLB في حالة مختلفة جداً عما تتوقعه الشفرة البرمجية.
تعمل هذه الآلية بشكل جيد عندما ينجح استدعاء دالة retrieve(). أما عند الفشل، فتعيد الدالة `luo_flb_retrieve_one()` الخطأ فوراً دون تخزين أي معلومات حول محاولة الاسترجاع أو رمز الخطأ الناتج عنها. وإذا حاول المستخدم استرجاع ملف آخر مسجل باستخدام نفس ملف FLB، فستحاول وحدة LUO استدعاء دالة retrieve() الخاصة بملف FLB مرة أخرى.
يُعد هذا الإجراء المتكرر (retry) مشكلة لنفس الأسباب المذكورة أعلاه. فمن المرجح أن يكون ملف FLB في حالة مختلفة جداً عما تتوقعه منطقية الاسترجاع بشكل طبيعي (على سبيل المثال، قد تكون بعض صفحات KHO قد تم استعادتها وتحريرها بالفعل).
لا توجد طريقة معقولة لمحاولة إجراء عملية الاسترجاع مرة أخرى. لذا يجب تذكر رمز الخطأ الذي أعادته دالة retrieve() وإعادته مباشرة عند أي محاولة إعادة تنفيذ.
يتم تحقيق ذلك عن طريق تغيير المتغير المنطقي `retrieved` إلى متغير صحيح (integer) باسم `retrieve_status`. تشير القيمة 0 إلى أن عملية الاسترجاع لم تُجرَ أبداً، وتشير القيم الموجبة إلى نجاح العملية، بينما تشير القيم السالبة إلى الفشل ويكون رمز الخطأ مساوياً للقيمة.
هذا الإجراء مشابه لـ commit f85b1c6af5bc ("liveupdate: luo_file: remember retrieve() status") الذي قام بنفس الشيء بالنسبة لملفات LUO.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.