CVE-2023-53790 in Linux
الملخص
بحسب VulDB • 28/06/2026
في نواة لينكس، تم حل الثغرة التالية:
bpf: تصفير الكائن المخصص من الـ slab في موزع ذاكرة bpf
حاليًا، قد يتم إعادة استخدام العنصر المحذوف (freed) فورًا في موزع ذاكرة bpf. وفي حالة خريطة htab map، ستؤدي عملية إعادة الاستخدام إلى تهيئة الحقول الخاصة داخل قيمة الخريطة مرة أخرى (مثل bpf_spin_lock)، ولكن إجراء البحث (lookup procedure) لا يزال بإمكانه الوصول إلى هذه الحقول الخاصة، مما قد يؤدي إلى توقف النظام بشكل قسري (hard-lockup) كما هو موضح أدناه:
NMI backtrace for cpu 16 CPU: 16 PID: 2574 Comm: htab.bin Tainted: G L 6.1.0+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), RIP: 0010:queued_spin_lock_slowpath+0x283/0x2c0 ...... Call Trace: <TASK> copy_map_value_locked+0xb7/0x170 bpf_map_copy_value+0x113/0x3c0 __sys_bpf+0x1c67/0x2780 __x64_sys_bpf+0x1c/0x20 do_syscall_64+0x30/0x60 entry_SYSCALL_64_after_hwframe+0x46/0xb0 ...... </TASK>
بالنسبة لخريطة htab map، تمامًا كما هو الحال في الحالة المخصصة مسبقًا (preallocated case)، لا حاجة إلى تهيئة هذه الحقول الخاصة داخل قيمة الخريطة مرة أخرى بمجرد أن تكون قد تم تهيئتها. وفي حالة خريطة htab map المخصصة مسبقًا، يتم تهيئة هذه الحقول من خلال __GFP_ZERO في دالة bpf_map_area_alloc()، لذا يجب القيام بشيء مشابه لخريطة htab غير المخصصة مسبقًا (non-preallocated) في موزع ذاكرة bpf. ولا حاجة إلى استخدام __GFP_ZERO لموزع ذاكرة bف الخاص بكل معالج (per-cpu)، لأن الدالة __alloc_percpu_gfp() تقوم بذلك ضمنيًا.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.