CVE-2022-49838

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: clear out_curr if all frag chunks of current msg are pruned<br /> <br /> A crash was reported by Zhen Chen:<br /> <br /> list_del corruption, ffffa035ddf01c18-&gt;next is NULL<br /> WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0<br /> RIP: 0010:__list_del_entry_valid+0x59/0xe0<br /> Call Trace:<br /> sctp_sched_dequeue_common+0x17/0x70 [sctp]<br /> sctp_sched_fcfs_dequeue+0x37/0x50 [sctp]<br /> sctp_outq_flush_data+0x85/0x360 [sctp]<br /> sctp_outq_uncork+0x77/0xa0 [sctp]<br /> sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp]<br /> sctp_side_effects+0x37/0xe0 [sctp]<br /> sctp_do_sm+0xd0/0x230 [sctp]<br /> sctp_primitive_SEND+0x2f/0x40 [sctp]<br /> sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp]<br /> sctp_sendmsg+0x3d5/0x440 [sctp]<br /> sock_sendmsg+0x5b/0x70<br /> <br /> and in sctp_sched_fcfs_dequeue() it dequeued a chunk from stream<br /> out_curr outq while this outq was empty.<br /> <br /> Normally stream-&gt;out_curr must be set to NULL once all frag chunks of<br /> current msg are dequeued, as we can see in sctp_sched_dequeue_done().<br /> However, in sctp_prsctp_prune_unsent() as it is not a proper dequeue,<br /> sctp_sched_dequeue_done() is not called to do this.<br /> <br /> This patch is to fix it by simply setting out_curr to NULL when the<br /> last frag chunk of current msg is dequeued from out_curr stream in<br /> sctp_prsctp_prune_unsent().