CVE-2021-46999

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: do asoc update earlier in sctp_sf_do_dupcook_a<br /> <br /> There&amp;#39;s a panic that occurs in a few of envs, the call trace is as below:<br /> <br /> [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI<br /> [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp]<br /> [] sctp_assoc_control_transport+0x1b9/0x210 [sctp]<br /> [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp]<br /> [] sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp]<br /> [] sctp_do_sm+0xc3/0x2a0 [sctp]<br /> [] sctp_generate_timeout_event+0x81/0xf0 [sctp]<br /> <br /> This is caused by a transport use-after-free issue. When processing a<br /> duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK<br /> and SHUTDOWN chunks are allocated with the transort from the new asoc.<br /> However, later in the sideeffect machine, the old asoc is used to send<br /> them out and old asoc&amp;#39;s shutdown_last_sent_to is set to the transport<br /> that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually<br /> belongs to the new asoc. After the new_asoc is freed and the old asoc<br /> T2 timeout, the old asoc&amp;#39;s shutdown_last_sent_to that is already freed<br /> would be accessed in sctp_sf_t2_timer_expire().<br /> <br /> Thanks Alexander and Jere for helping dig into this issue.<br /> <br /> To fix it, this patch is to do the asoc update first, then allocate<br /> the COOKIE-ACK and SHUTDOWN chunks with the &amp;#39;updated&amp;#39; old asoc. This<br /> would make more sense, as a chunk from an asoc shouldn&amp;#39;t be sent out<br /> with another asoc. We had fixed quite a few issues caused by this.