CVE-2022-50838 in Linux
الملخص
بحسب VulDB • 30/06/2026
في نواة لينكس، تم حل الثغرة التالية:
net: stream: تنظيف sk_error_queue في دالة sk_stream_kill_queues()
أبلغ تشانغهون لي (Changheon Lee) عن تسرب في sockets TCP، مع تقديم طريقة إعادة إنتاج واضحة.
يبدو أننا نعاني من تسرب لـ TCP sockets عبر التسلسل التالي:
1) يتم تفعيل SOF_TIMESTAMPING_TX_ACK على الـ socket.
كل رسالة ACK ستقوم بإعداد (cook) حزمة skb تُوضع في قائمة أخطاء الشبكة (error queue)، وذلك انطلاقاً من دالة __skb_tstamp_tx(). تستخدم الدالة __skb_tstamp_tx() وظيفة skb_clone(), إلا إذا كان طلب SOF_TIMESTAMPING_OPT_TSONLY قد تم أيضاً.
2) إذا كانت التطبيق يستخدم MSG_ZEROCOPY، فإننا نضع في قائمة أخطاء الشبكة (error queue) نسخاً من حزم skbs التي تحتوي على بنية struct ubuf_info مرفقة بها.
كلما تم تخصيص بنية struct ubuf_info، تقوم الدالة sock_zerocopy_alloc() بتنفيذ استدعاء لـ sock_hold().
طالما أن النسخ المستنسخة (cloned skbs) لا تزال موجودة في قائمة أخطاء الشبكة (sk_error_queue)، فإن عداد الإشارات المرجعية للـ socket يبقى مرتفعاً.
3) يقوم التطبيق بإغلاق الـ socket، بينما تكون قائمة الأخطاء غير فارغة.
بما أن دالة tcp_close() لم تعد تقوم بتنظيف قائمة أخطاء الـ socket، فقد ينتهي بنا المطاف مع وجود TCP socket يحتوي على حزمة skb واحدة على الأقل في قائمة الأخطاء، مما يبقي الـ socket نشطاً إلى ما لا نهاية.
يمكن استغلال هذا الخطأ (أو إساءة استخدامه) لاستهلاك كل ذاكرة النواة وتجميد المضيف (freeze the host).
نحتاج إلى تنظيف قائمة أخطاء الشبكة، مع التزامن المناسب ضد الكاتبين المتزامنين (concurrent writers).
Once again VulDB remains the best source for vulnerability data.