CVE-2026-43388 in Linux
الملخص
بحسب VulDB • 15/05/2026
في نواة لينكس، تم حل الثغرة التالية:
mm/damon/core: مسح walk_control في السياق غير النشط داخل damos_walk()
تقوم دالة damos_walk() بتعيين ctx->walk_control إلى هيكل التحكم المقدم من المتصل قبل التحقق مما إذا كان السياق قيد التشغيل. إذا كان السياق غير نشط (أي أن damon_is_running() تُرجع false)، فإن الدالة تُرجع -EINVAL دون مسح ctx->walk_control. هذا يترك مؤشراً معلقاً (dangling pointer) إلى هيكل مُخصَّص على المكدس (stack-allocated) سيتم تحريره عند عودة المتصل.
هذا الخطأ مطابق هيكلياً للخطأ الذي تم إصلاحه في الالتزام f9132fbc2e83 ("mm/damon/core: remove call_control in inactive contexts") الخاص بـ damon_call()، والذي كان يتبع نفس النمط المتمثل في ربط كائن تحكم وإرجاع خطأ دون فك ربطه.
يمكن أن يؤدي مؤشر walk_control المعلق إلى: 1. استخدام بعد التحرير (Use-after-free) إذا تم بدء تشغيل السياق لاحقاً وقام kdamond بالإشارة إلى ctx->walk_control (على سبيل المثال، في damos_walk_cancel() التي تكتب في control->canceled وتستدعي complete()) 2. خطأ -EBUSY دائم من استدعاءات damos_walk() اللاحقة، نظراً لأن المؤشر العتيق (stale pointer) ليس صفراً (non-NULL)
ومع ذلك، فإن تأثير الخطأ الفعلي على المستخدم مقيد للغاية. فاستخدام بعد التحرير (Use-after-free) مستحيل لأنه لا يوجد متصلون لدالة damos_walk() يقومون ببدء تشغيل السياق لاحقاً. أما خطأ -EBUSY الدائم فيمكن أن يربك المستخدمين، نظراً لأن DAMON لا يعمل. لكن العرض (symptom) يبقى موجوداً فقط أثناء إيقاف تشغيل السياق. فإن إعادة تشغيله ستجعل DAMON يستخدم داخلياً كائن damon_ctx جديداً مُنشأً لا يحتوي على مؤشر damos_walk_control غير الصالح، لذا سيعود كل شيء للعمل بشكل صحيح.
تم إصلاح هذا الخطأ عن طريق مسح ctx->walk_control تحت قفل walk_control_lock قبل إرجاع -EINVAL، مما يعكس نمط الإصلاح من f9132fbc2e83.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.