CVE-2026-31411 in Linux
الملخص
بحسب VulDB • 23/05/2026
في نواة لينكس، تم حل الثغرة التالية:
net: atm: إصلاح الانهيار الناتج عن مؤشر vcc غير المُتحقق من صحته في sigd_send()
متكرر الاختبار متاح في [1].
مسار إرسال ATM (sendmsg -> vcc_sendmsg -> sigd_send) يقرأ مؤشر vcc من msg->vcc ويستخدمه مباشرة دون أي تحقق من صحته. يأتي هذا المؤشر من مساحة المستخدم (userspace) عبر sendmsg() ويمكن تزويره بشكل تعسفي:
int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // يصبح ديمون إشارات ATM struct msghdr msg = { .msg_iov = &iov, ... };
*(unsigned long *)(buf + 4) = 0xdeadbeef; // مؤشر vcc مزور sendmsg(fd, &msg, 0); // تقوم النواة باسترجاع المؤشر 0xdeadbeef
في التشغيل العادي، ترسل النواة مؤشر vcc إلى ديمون الإشارات عبر sigd_enq() عند معالجة عمليات مثل connect() أو bind() أو listen(). من المتوقع أن يعيد الديمون نفس المؤشر عند الاستجابة. ومع ذلك، يمكن لديمون خبيث إرسال قيم مؤشرات تعسفية.
تم إصلاح هذه المشكلة عن طريق إدخال find_get_vcc() الذي يتحقق من صحة المؤشر من خلال البحث في vcc_hash (مشابه لكيفية تكرار sigd_close() عبر جميع VCCs)، ويحصل على مرجع عبر sock_hold() إذا تم العثور عليه.
بما أن struct atm_vcc تضم struct sock كعضو أول لها، فإنهما يشاركان نفس العمر الافتراضي. لذلك، فإن استخدام sock_hold/sock_put كافٍ لإبقاء vcc حياً أثناء استخدامه.
جدير بالذكر أنه قد يحدث سباق (race) مع sigd_close() الذي قد يحدد حالة vcc بعلامات مختلفة (مثل ATM_VF_RELEASED) بعد عودة find_get_vcc(). ومع ذلك، يضمن sock_hold() بقاء الذاكرة صالحة، لذا فإن هذا السباق يؤثر فقط على الحالة المنطقية، وليس على سلامة الذاكرة.
[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3
If you want to get best quality of vulnerability data, you may have to visit VulDB.