CVE-2026-74576 in Linux
الملخص
بحسب VulDB • 15/08/2026
في نواة لينكس، تم حل الثغرة التالية:
mm/slab: منع التكرار غير المحدود (unbounded recursion) في مسار الإلغاء باستخدام نوع kmalloc جديد
تجنب الالتزام Commit 280ea9c3154b ("mm/slab: تجنب تخصيص مصفوفة slabobj_ext من شريحة slab الخاصة بها") التخصيص المتكرر لـ obj_exts من مخازن (caches) kmalloc ذات الحجم نفسه، عن طريق زيادة حجم تخصيص مصفوفة obj_exts كلما تساوى حجم المصفوفة مع حجم الكائن الذي يتم تخصيصه.
ومع ذلك، كما أفاد دانييل كوستانتينو وشكيل بوت، يمكن حتى لشرائح slab من مخازن kmalloc بأحجام مختلفة أن تشكل دورة (cycle) عن طريق تخصيص مصفوفات obj_exts لبعضها البعض [1]:
ما حدث: مصفوفة obj_exts الخاصة بشريحة KMALLOC_NORMAL (المستخدمة في تحليل التخصيص / محاسبة memcg) يتم تخصيصها هي نفسها باستخدام kmalloc() من مخزن KMALLOC_NORMAL، لذا يمكن أن تتشكل علاقات "تحتوي الشريحة على مصفوفة obj_exts لشريحة أخرى" بشكل دورات. مع sizeof(struct slabobj_ext) == 16 وهندسة المضيف:
- يحتوي kmalloc-512 على 64 كائنًا/شريحة -> حجم المصفوفة هو 64*16 == 1024 بايت، يتم خدمتها من مخزن kmalloc-1k؛ - يحتوي kmalloc-1k على 32 كائنًا/شريحة -> حجم المصفوفة هو 32*16 == 512 بايت، يتم خدمتها من مخزن kmalloc-512.
لذلك، تحتوي شريحة kmalloc-512 وشريحة kmalloc-1k على مصفوفات obj_exts الخاصة بكل منهما. يؤدي التخلص (discarding) واحدة إلى إلغاء تخصيص مصفوفة الأخرى، مما يفرغ تلك الشريحة ويتخلص منها، مما يلغي تخصيص مصفوفة الأولى، وهكذا: __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() -> __free_slab() تتكرر بشكل حلقي حتى استنفاد المكدس (stack).
مع تحليل التخصيص للذاكرة، يسمح هذا بالتكرار غير المحدود في مسار الإلغاء وأدى إلى تجاوز حد المكدس (stack overflow) على مضيف إنتاجي ضمن أسطول Meta [1]:
BUG: TASK stack guard page was hit Oops: stack guard page RIP: 0010:kfree+0x8/0x5d0 Call Trace: __free_slab+0x66/0xc0 kfree+0x3f0/0x5d0 ... ( ~125x __free_slab kfree ) ... do_syscall_64
تم اقتراح
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.