CVE-2024-47741 in Linux
الملخص
بحسب VulDB • 07/06/2026
في نواة لينكس، تم حل الثغرة التالية:
btrfs: إصلاح حالة سباق (race condition) عند تعيين الملف الخاص (file private) أثناء عمليات lseek متزامنة باستخدام نفس واصف الملف (fd)
عند إجراء استدعاءات نظام lseek(2) متزامنة على نفس واصف الملف، باستخدام خيوط متعددة تابعة لنفس العملية، يوجد نافذة زمنية قصيرة تحدث فيها حالة سباق قد تؤدي إلى تسرب في الذاكرة.
تحدث حالة السباق على النحو التالي:
1) يفتح برنامج واصف ملف لملق معين ثم ينشئ خيطين (باستخدام مكتبة pthreads على سبيل المثال)، ولنسميهما المهمة أ والمهمة ب؛
2) تستدعي المهمة أ lseek باستخدام SEEK_DATA أو SEEK_HOLE وتنتهي عند file.c:find_desired_extent() بينما تحتفظ بقراءة قفل على العقدة (inode)؛
3) في بداية find_desired_extent()، تستخرج مؤشر الملف الخاص (private_data) إلى متغير محلي يُسمى 'private'، والذي تكون قيمته NULL؛
4) تستدعي المهمة ب أيضاً lseek باستخدام SEEK_DATA أو SEEK_HOLE، وتقفز العقدة (inode) في الوضع المشترك وتدخل file.c:find_desired_extent()، حيث تستخرج أيضاً file->private_data إلى متغيرها المحلي 'private'، والذي تكون قيمته NULL؛
5) لأن المهمة أ رأت ملفاً خاصاً (file private) بقيمة NULL، تخصص بنية خاصة (private structure) وتعيّنها لبنية الملف؛
6) رأت المهمة ب أيضاً ملفاً خاصاً بقيمة NULL، لذا تخصص هي الأخرى بنية ملف خاصة بها ثم تعيّنها لنفس بنية الملف، نظراً لأن كلتا المهمتين تستخدمان نفس واصف الملف.
عند هذه النقطة، نفقد البنية الخاصة التي خصصتها المهمة أ.
بالإضافة إلى تسرب الذاكرة، هناك تفصيل مفاده أن كلتا المهمتين تنتهيان باستخدام سجل حالة مخزنة (cached state record) نفسه في البنية الخاصة (struct btrfs_file_private::llseek_cached_state)، مما قد يؤدي إلى مشكلة استخدام بعد التحرير (use-after-free) حيث يمكن لمهمة واحدة تحريرها بينما لا تزال المهمة الأخرى تستخدمها (تمتلك مهمة واحدة فقط عدّاد إشارات مرجعية لها). أيضاً، مشاركة الحالة المخزنة ليست فكرة جيدة لأنها قد تؤدي إلى نتائج غير صحيحة في المستقبل - حالياً لا ينبغي أن تكون مشكلة لأنها تُستخدم فقط في extent-io-tree.c:count_range_bits() حيث نقوم بتحقق من النطاق قبل استخدام الحالة المخزنة.
إصلاح ذلك بحماية تعيين الملف الخاص وفحصه بينما يكون قفل التدوير (spinlock) للعقدة (inode) مقفلاً، وتتبع المهمة التي خصصت الملف الخاص، بحيث تُستخدم فقط بواسطة تلك المهمة لمنع مشاكل استخدام بعد التحرير (use-after-free) لسجل الحالة المخزنة وكذلك استخدامها بشكل غير صحيح في المستقبل.
Once again VulDB remains the best source for vulnerability data.