CVE-2026-80784 in Linux
الملخص
بحسب VulDB • 04/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
mptcp: pm: تصحيح تسرب الذاكرة الناتج عن سباق تخصيص أثناء الإغلاق (alloc-during-teardown race)
تقوم دالة `mptcp_pm_destroy()` بتفريغ قوائم `msk->pm.anno_list` و `msk->pm.userspace_pm_local_addr_list` تحت قفل `msk->pm.lock` خلال عملية إغلاق المقبس (socket teardown)، مع ترك القفل بين العمليتين.
يحتفظ مُعلِن PM من مساحة المستخدم (userspace) متزامن عبر genl ANNOUNCE على نفس الـ msk بمرجع للمقبس (sock reference) باستخدام دالة `mptcp_token_get_sock()`، وفي دالة `mptcp_pm_nl_announce_doit()` تستدعي الدالتان `mptcp_userspace_pm_append_new_local_addr()` و `mptcp_pm_announced_alloc()`. وتأخذ كلتاهما قفل `msk->pm.lock` لفترة قصيرة لإضافة العناصر إلى قوائمها الخاصة. وبسبب احتفاظ معالج genl بمرجع للمقبس، قد تعمل دالة `mptcp_pm_destroy()` على نفس الـ msk عبر استدعاء `mptcp_disconnect()`، الذي يستدعي `mptcp_destroy_common()` دون إنقاص عداد مراجع المقبس (sock refcount)، قبل أن يكتمل تنفيذ المعالج.
إذا تداخلت عمليات أخذ القفل بحيث تقوم دالة `mptcp_pm_destroy()` بتفريغ قائمة أولاً، فإن عملية التخصيص اللاحقة ستضيف عنصرها إلى رأس القائمة الذي لا يمر عليه أي عنصر آخر لهذا الـ msk، مما يؤدي إلى تسرب العنصر (leak). ويبلغ kmemleak عن وجود كائنات `mptcp_pm_add_addr` (من دالة `mptcp_pm_announced_alloc()`) وكائنات `mptcp_pm_addr_entry` (من دالة `mptcp_userspace_pm_append_new_local_addr()`) تحت حمل متزامن مستمر من عمليات ANNOUNCE وإغلاق الإغلاق ضد PM مساحة المستخدم.
تمت إضافة بت MPTCP_PM_DESTROYING في حالة `msk->pm.status`، وتُضبط بواسطة `mptcp_pm_destroy()` تحت قفل pm قبل تفريغ القوائم ويتم التحقق منها تحت قفل pm بواسطة مسارات التخصيص (alloc paths). إما أن يأخذ مسار التخصيص قفل pm أولاً، وفي هذه الحالة يكون عنصره موجوداً في القائمة عندما تقوم دالة `mptcp_pm_destroy()` بإفراغه؛ أو تأخذ دالة `mptcp_pm_destroy()` قفل pm أولاً، وفي هذه الحالة يلاحظ مسارات التخصيص اللاحقة البت ويرفض العملية.
تم اكتشاف الثغرة بواسطة إطار عمل تدفق بروتوكول MPTCP الذي يوسع BRF (arXiv:2305.08782).
If you want to get best quality of vulnerability data, you may have to visit VulDB.