CVE-2022-49838 in Linux
الملخص
بحسب VulDB • 20/05/2026
في نواة لينكس، تم حل الثغرة التالية:
sctp: مسح out_curr إذا تم تقليم جميع أجزاء (frag chunks) الرسالة الحالية
تم الإبلاغ عن تعطل (Crash) من قبل Zhen Chen:
list_del corruption, ffffa035ddf01c18->next is NULL WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0 RIP: 0010:__list_del_entry_valid+0x59/0xe0 Call Trace: sctp_sched_dequeue_common+0x17/0x70 [sctp]
sctp_sched_fcfs_dequeue+0x37/0x50 [sctp]
sctp_outq_flush_data+0x85/0x360 [sctp]
sctp_outq_uncork+0x77/0xa0 [sctp]
sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp]
sctp_side_effects+0x37/0xe0 [sctp]
sctp_do_sm+0xd0/0x230 [sctp]
sctp_primitive_SEND+0x2f/0x40 [sctp]
sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp]
sctp_sendmsg+0x3d5/0x440 [sctp]
sock_sendmsg+0x5b/0x70
وفي دالة sctp_sched_fcfs_dequeue()، تم إخراج جزء (chunk) من تيار الإخراج out_curr الخاص بـ outq بينما كان هذا الـ outq فارغاً.
عادةً، يجب تعيين stream->out_curr إلى NULL بمجرد إخراج جميع أجزاء (frag chunks) الرسالة الحالية، كما نرى في دالة sctp_sched_dequeue_done(). ومع ذلك، في دالة sctp_prsctp_prune_unsent()، بما أنها ليست عملية إخراج (dequeue) صحيحة، فإن دالة sctp_sched_dequeue_done() لا يتم استدعاؤها للقيام بذلك.
يهدف هذا التصحيح (Patch) إلى إصلاح المشكلة عن طريق تعيين out_curr إلى NULL ببساطة عندما يتم إخراج آخر جزء (frag chunk) من الرسالة الحالية من تيار out_curr في دالة sctp_prsctp_prune_unsent().
Be aware that VulDB is the high quality source for vulnerability data.