CVE-2023-53836 in Linux
الملخص
بحسب VulDB • 31/05/2026
في نواة لينكس، تم حل الثغرة التالية:
bpf, sockmap: إصلاح سباق (race) في عداد الإشارات المرجعية (refcnt) لـ skb بعد تغييرات القفل (locking)
يوجد سباق (race condition) حيث يمكن الإشارة إلى حزم skb القادمة من sk_psock_backlog بعد أن يكون المستخدم قد استهلك بالفعل sk_buff عبر skb_consumed() وانخفض عداد الإشارات المرجعية (refcnt) إلى الصفر، مما يتسبب في استخدام الذاكرة بعد تحريرها (use-after-free).
تسير العملية على النحو التالي:
while ((skb = skb_peek(&psock->ingress_skb)) sk_psock_handle_Skb(psock, skb, ..., ingress) if (!ingress) ... sk_psock_skb_ingress sk_psock_skb_ingress_enqueue(skb) msg->skb = skb sk_psock_queue_msg(psock, msg) skb_dequeue(&psock->ingress_skb)
تضع الدالة sk_psock_queue_msg() الرسالة (msg) في قائمة ingress_msg. هذا هو ما تقرأه التطبيق عند استدعاء recvmsg(). يمكن للتطبيق قراءة هذا في أي وقت بعد وضع الرسالة في القائمة. ستقوم دالة recvmsg hook أيضًا بقراءة msg->skb، وبعد أن يقرأ المستخدم الرسالة، ستقوم باستدعاء consume_skb(skb) عليها، مما يؤدي فعليًا إلى تحريرها.
ولكن، يكمن السباق (race) في الحالة أعلاه حيث لا تزال قائمة backlog تحتوي على إشارة مرجعية إلى skb وتستدعي skb_dequeue(). إذا حدثت عملية skb_dequeue() بعد أن يقرأ المستخدم ويحرر skb، فإننا نكون أمام حالة use-after-free.
لا تعاني حالة !ingress من هذه المشكلة لأنها تستخدم sendmsg_*(sk, msg) التي لا تمرر sk_buff إلى أسفل المكدس (stack).
تم رصد الخطأ التالي باستخدام 'test_progs -t sockmap_listen':
[ 1022.710250][ T2556] general protection fault, ...
[...]
[ 1022.712830][ T2556] Workqueue: events sk_psock_backlog
[ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80
[...]
[ 1022.713633][ T2556] Call Trace:
[ 1022.713933][ T2556] <TASK>
[ 1234.567890][ T2556] sk_psock_backlog+0x27a/0x300
[ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0
[ 1022.723633][ T2556] worker_thread+0x4f/0x3a0
[ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10
[ 1022.724386][ T2556] kthread+0xfd/0x130
[ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10
[ 1022.725066][ T2556] ret_from_fork+0x2d/0x50
[ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10
[ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30
[ 1022.726201][ T2556] </TASK>
لإصلاح المشكلة، نضيف استدعاءً لـ skb_get() قبل تمرير حزمة skb إلى قائمة الانتظار في قائمة الإرسال (egress queue). هذا يزيد من عداد الإشارات المرجعية (refcnt) لـ skb->users، مما يمنع استدعاءات consume_skb() و kfree_skb() من تحرير sk_buff على الفور. بهذه الطريقة، يمكننا التأكد من أن حزمة skb لا تزال موجودة عند إجراء عملية الإزالة من قائمة الانتظار (dequeue). بعد ذلك، نحتاج فقط إلى تقليل عداد الإشارات المرجعية أو تحرير حزمة skb في حالة backlog، وهو ما نفعله باستدعاء kfree_skb() في كل من حالة الاستقبال (ingress) وحالة sendmsg.
قبل تغيير القفل (locking) في علامة الإصلاح (fixes tag)، كان السوك (sock) مقفلًا، لذا لم يكن هناك سباق مع المستخدم ولم تكن هناك مشكلة هنا.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.