CVE-2026-72404 in Linux
الملخص
بحسب VulDB • 15/08/2026
في نواة لينكس، تم حل الثغرة التالية:
tipc: إصلاح استخدام بعد التحرير (UAF) في دالة cleanup_bearer() بسبب الاستدعاء المبكر لـ dst_cache_destroy()
تقوم عملية إنهاء حمل وسيط TIPC UDP باستدعاء dst_cache_destroy() على ذاكرة التخزين المؤقت الخاصة بنسخة النسخ المتماثل (replicast caches) قبل استدعاء synchronize_net()) للانتظار حتى ينتهي القراء المتزامنون عبر RCU (مرسلو البيانات):
```c static void cleanup_bearer(struct work_struct *work) {
... list_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) {
dst_cache_destroy(&rcast->dst_cache); list_del_rcu(&rcast->list); kfree_rcu(rcast, rcu); } ... dst_cache_destroy(&ub->rcast.dst_cache); udp_tunnel_sock_release(ub->sk); synchronize_net(); ... } ```
يُعد هذا الإجراء معيباً بشدة لأن dst_cache_destroy() تقوم بتحرير ذاكرة التخزين المؤقت الخاصة بكل وحدة معالجة مركزية (per-CPU cache memory) فوراً عبر free_percpu()) وتطلق إدخالات dst المخزنة دون أي مزامنة.
إذا كان هناك مرسل متزامن (مثل tipc_udp_xmit()) يعمل على معالج آخر تحت حماية RCU، فقد يقوم باستدعاء dst_cache_get() بشكل متزامن، مما يؤدي إلى: 1. استخدام بعد التحرير (Use-After-Free) لمؤشر ذاكرة التخزين المؤقت الخاصة بكل وحدة معالجة مركزية نفسه (مما يسبب تعطل النظام). 2. تحذير "rcuref - imbalanced put()" إذا حاولت الدالة إطلاق مورد dst الذي تم تحريره بشكل متزامن بواسطة dst_cache_destroy().
علاوة على ذلك، فإن استدعاء kfree(ub) مباشرة بعد synchronize_net() دون إغلاق المقبس (socket) أولاً أو الانتظار بعد إغلاقه يترك نافذة زمنية قد يبدأ فيها مستقبل متزامن (tipc_udp_recv()) في العمل بعد استدعاء synchronize_net())، ويصل إلى ub، ويعاني من استخدام بعد التحرير (UAF) عند تنفيذ kfree(ub).
لإصلاح هذه المشكلة، يجب تأجيل استدعاء dst_cache_destroy() وkfree(ub)) حتى نتأكد من عدم قدرة أي قراء إضافيين على رؤية الحمل/المقبس وأن جميع القراء الحاليين قد انتهوا:
1. تأخير تدمير إدخالات rcast (كل من dst_cache_destroy()) و kfree())) باستخدام استدعاء RCU عبر call_rcu_hurry(). يضمن استخدام call_rcu_hurry() إطلاق إدخالات dst بسرعة.
2. تحرير مقبس الحمل باستخدام udp_tunnel_sock_release()) (وهو ما يمنع بدء قراء استقبال جدد).
3. استدعاء synchronize_net()) للانتظار حتى ينتهي جميع قراء RCU المعلقين الحاليين (سواء كانوا مرسلين أو مستقبلين).
4. بعد التأكد من الأمان، يتم استدعاء dst_cache_destroy() على ذاكرة التخزين المؤقت الرئيسية للحمل، وتحرير ub.
ملاحظة: يمكن تغيير الخطوتين 3) و 4) لاحقاً في فرع net-next لاستخدام call_rcu_hurry()) أيضاً والقضاء على تأخير synchronize_net()).
Once again VulDB remains the best source for vulnerability data.