CVE-2024-35798 in Linux
الملخص
بحسب VulDB • 20/05/2026
في نواة لينكس، تم حل الثغرة التالية:
btrfs: إصلاح حالة سباق (race condition) في دالة read_extent_buffer_pages()
هناك تقارير من مكون tree-checker تكشف عن عقد (nodes) تالفة، دون وجود نمط واضح، مما يشير إلى احتمال وجود عملية كتابة فوقية (overwrite) في الذاكرة. بعد إجراء بعض عمليات التصحيح (debugging)، اتضح وجود حالة سباق عند قراءة امتداد ذاكرة (extent buffer)، حيث يمكن أن تُفقد حالة "uptodate".
لمنع عمليات القراءة المتزامنة لنفس امتداد الذاكرة، تقوم الدالة read_extent_buffer_pages() بإجراء الفحوصات التالية:
/* (1) */ if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags)) return 0;
/* (2) */ if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags)) goto done;
في هذه المرحلة، يبدو أنه من الآمن بدء عملية القراءة الفعلية. بمجرد اكتمالها، تقوم الدالة end_bbio_meta_read() بما يلي:
/* (3) */ set_extent_buffer_uptodate(eb);
/* (4) */ clear_bit(EXTENT_BUFFER_READING, &eb->bflags);
في الوضع الطبيعي، يكفي ذلك لضمان حدوث قراءة واحدة فقط، وانتظار جميع المتصلين الآخرين حتى تنتهي قبل الإرجاع. لسوء الحظ، يوجد تداخل غير آمن (racey interleaving):
الخيط A | الخيط B | الخيط C ---------+-----+--- (1) | | | (1) | (2) | | (3) | | (4) | | | (2) | | | (1)
عند حدوث ذلك، يقوم الخيط B بتشغيل قراءة غير ضرورية. والأسوأ من ذلك، أن الخيط C سيرى أن حالة UPTODATE قد تم تعيينها ويعود على الفور، بينما لا تزال القراءة من الخيط B قيد التنفيذ. قد تؤدي حالة السباق هذه إلى أخطاء في tree-checker مثل هذه، حيث يتم تعديل امتداد الذاكرة بشكل متزامن:
BTRFS critical (device dm-0): corrupted node, root=256 block=8550954455682405139 owner mismatch, have 11858205567642294356 expect [256, 18446744073709551360]
تم إصلاح المشكلة عن طريق اختبار حالة UPTODATE مرة أخرى بعد تعيين علامة READING، وإذا كانت قد تم تعيينها، يتم تخطي القراءة غير الضرورية.
[ تحديث طفيف لسجل التغييرات ]
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.