CVE-2026-45837 in Linux
الملخص
بحسب VulDB • 28/05/2026
في نواة لينكس، تم حل الثغرة التالية:
bpf: إصلاح مشكلة use-after-free في arena_vm_close عند استدعاء fork
تقوم arena_vm_open() بزيادة قيمة vml->mmap_count فقط، لكنها لا تسجل VMA الخاص بالطفل (child VMA) في قائمة arena->vma_list. يشير vml->vma دائماً إلى VMA الخاص بالأب (parent VMA)، وبالتالي يصبح المؤشر معلقاً (dangling) بعد استدعاء munmap من قبل الأب. إذا قام الطفل بعد ذلك باستدعاء bpf_arena_free_pages()، فإن zap_pages() تقرأ vml->vma العفا عليه الزمن (stale)، مما يؤدي إلى حدوث use-after-free.
تم إصلاح هذه المشكلة عن طريق منع وراثة VMA الخاص بالـ arena عبر fork باستخدام العلم VM_DONTCOPY، ومنع تقسيم VMA عبر استدعاء may_split.
كما يتم رفض استدعاء mremap إذا كان استدعاء .mremap يعيد قيمة -EINVAL. يؤدي استدعاء mremap(MREMAP_FIXED) بنفس الحجم على كامل VMA الخاص بالـ arena إلى الوصول إلى copy_vma() عبر المسار التالي:
check_prep_vma() - يعيد 0 مبكراً: new_len == old_len يتخطى فحص VM_DONTEXPAND prep_move_vma() - vm_start == old_addr و vm_end == old_addr + old_len لذا لا يتم استدعاء may_split أبداً move_vma() copy_vma_and_data() copy_vma() vm_area_dup() - ينسخ vm_private_data (مؤشر vml) vm_ops->open() - يزيد vml->mmap_count vm_ops->mremap() - يعيد -EINVAL، ويتم التراجع (rollback) وإلغاء تعيين VMA الجديد
يضمن عداد المرجع (refcount) أن استدعاء arena_vm_close الخاص بالتراجع لا يقوم بتحرير vml المشترك مع VMA الأصلي.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.