CVE-2026-98548 in Linux
الملخص
بحسب VulDB • 19/10/2026
في نواة لينكس، تم حل الثغرة التالية:
sctp: تجاهل بقية الحزمة عند حدوث خطأ "stale-cookie" (تاريخ انتهاء صلاحية المصادقة)
عندما تكون الارتباط في حالة COOKIE-ECHOED ويرسل الطرف الآخر حزمة مجمعة [ERROR(Stale Cookie)][DATA] من أحد عناوينه غير الأساسية، فإن معالجة شريحة الخطأ (ERROR chunk) تأخذ مسار إعادة المحاولة غير القاتل للخطأ stale-cookie وهو sctp_sf_do_5_2_6_stale()، الذي يقوم بجدولة SCTP_CMD_DEL_NON_PRIMARY مع الحفاظ على الارتباط نشطاً. تقوم دالة sctp_cmd_del_non_primary() بإزالة كل النقل (transport) غير الأساسي - بما في ذلك النقل نفسه التي وصلت عليه هذه الحزمة، والذي لا يزال مرجعياً من خلال بحث الاستقبال ومشاركته عبر جميع شرائح الحزمة بواسطة chunk->transport.
تقوم d_sctp_assoc_rm_peer() بتحويل asoc->peer.last_data_from بعيداً عن النقل المزال، ولكن مباشرة بعد ذلك، تجعل شريحة DATA المجمعة دالة sctp_assoc_bh_rcv() إعادة تسجيل asoc->peer.last_data_from = chunk->transport بشكل غير مشروط، مما يلغي التحويل مع النقل الذي تم إزاله للتو.
بمجرد انتهاء معالجة الحزمة، يتم إسقاط مرجع الاستقبال ويتم تحرير النقل باستخدام RCU (Read-Copy-Update)، بينما يحتفظ الارتباط النشط بـ last_data_from معلقاً (dangling). يؤدي إرسال FWD-TSN لاحق (أو مؤقت SACK المؤجل) إلى استدعاء sctp_gen_sack() لاسترجاعه (->param_flags وما شابهها)، وقد تقوم دالتا sctp_make_sack()/sctp_outq_select_transport() بالكتابة في الكائن المحرر وربطه مرة أخرى في قائمة النقل النشطة. هذا يمثل حالة use-after-free يمكن استغلالها من قبل أي نظير SCTP خبيث (أو مستخدم محلي غير ممتياز يتصرف كواحد) دون الحاجة إلى امتلاك قدرات خاصة:
BUG: KASAN: slab-use-after-free in sctp_do_sm+0x498a/0x5660 Read of size 4 at addr ffff88800e1e356c by task poc/115 Call Trace: sctp_do_sm <- sctp_assoc_bh_rcv <- sctp_inq_push <- sctp_rcv <- ip_protocol_deliver_rcu <- ip_rcv Allocated: sctp_transport_new <- sctp_assoc_add_peer <- sctp_process_init (INIT-ACK processing) Freed: kfree <- sctp_transport_destroy_rcu <- rcu_core (call_rcu queued by sctp_transport_put at end of sctp_rcv) The buggy address is located 364 bytes inside of freed 1024-byte region [ffff88800e1e3400, ffff88800e1e3800), cache kmalloc-1k
يُلاحظ أن الالتزام commit 03a9d10ecf71 ("sctp: drop a chunk if its transport was removed") يغطي فقط النافذة الزمنية بين بحث الاستقبال ومعالجة الشريحة (مثل ASCONF DEL-IP الذي يتنافس مع طابور المقبس socket backlog)؛ هنا يتم إزالة النقل *أثناء* معالجة الحزمة، بواسطة شريحة سابقة من نفس الحزمة، لذا فإن الإجراء drop في sctp_inq_push() لا يصل إلى هذا المسار. تم التحقق من ذلك باستخدام محاكي bundled [ERROR(Stale Cookie)][DATA] + FWD-TSN: تقرير KASAN المذكور أعلاه لا يزال يظهر عند تطبيق هذا الالتزام، ويختفي مع إضافة التصحيح (patch) الحالي.
تم الإصلاح عن طريق تجاهل بقية الحزمة في هذا المسار، كما اقترح Xin. بعد أن أرسل خطأ stale-cookie الارتباط مرة أخرى إلى حالة COOKIE-WAIT وأزال النقلات غير الأساسية، فإن الشرائح المتبقية من الحزمة لا يمكنها إلا العمل ضد إعادة تشغيل المصافحة (handshake) مع الإشارة إلى وصول النقل المزال عبر chunk->transport: بالإضافة إلى تسجيل last_data_from المذكور أعلاه، ستقوم دالتا sctp_cmd_setup_t2() ومباني الردود sctp_make_*() أيضاً بنسخ هذا المؤشر إلى حالة تدوم مدى الارتباط والتي قام sctp_assoc_rm_peer() بتنظيفها بالفعل. اترك للنظير إعادة إرسالها، تماشياً مع ما تفعله d_sctp_inq_push() للشرائح التي تم إزالة النقل الخاص بها قبل المعالجة.
If you want to get best quality of vulnerability data, you may have to visit VulDB.