Vulnerabilidad en kernel de Linux (CVE-2021-46999)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: haga una actualización anterior en sctp_sf_do_dupcook_a Hay un pánico que ocurre en algunos de los entornos, el seguimiento de la llamada es el siguiente: [] falla de protección general, ... 0x29acd70f1000a: 0000 [#1] SMP PTI [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp] [] sctp_assoc_control_transport+0x1b9/0x210 [sctp] [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp] [] sctp_cmd_interpreter.isra. 21+0x1231/0x1a10 [sctp] [] sctp_do_sm+0xc3/0x2a0 [sctp] [] sctp_generate_timeout_event+0x81/0xf0 [sctp] Esto se debe a un problema de use-after-free del transporte. Al procesar un fragmento COOKIE-ECHO duplicado en sctp_sf_do_dupcook_a(), tanto los fragmentos COOKIE-ACK como SHUTDOWN se asignan con el transort del nuevo asoc. Sin embargo, más adelante en la máquina de efectos secundarios, el antiguo asoc se utiliza para enviarlos y el Shutdown_last_sent_to del antiguo asoc se configura en el transporte al que se adjuntó el fragmento SHUTDOWN en sctp_cmd_setup_t2(), que en realidad pertenece al nuevo asoc. Después de que se libera el new_asoc y se agota el tiempo de espera T2 del antiguo asoc, se accederá al Shutdown_last_sent_to del antiguo asoc que ya está liberado en sctp_sf_t2_timer_expire(). Gracias Alexander y Jere por ayudarnos a profundizar en este problema. Para solucionarlo, este parche consiste en realizar primero la actualización de asoc y luego asignar los fragmentos COOKIE-ACK y SHUTDOWN con el antiguo asoc 'actualizado'. Esto tendría más sentido, ya que un fragmento de una asoc no debería enviarse con otra asoc. Hemos solucionado bastantes problemas causados por esto.