Descripción
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sctp: descartar el resto del paquete ante un error de cookie obsoleta Cuando una asociación está en estado COOKIE-ECHOED y el par envía un paquete agrupado [ERROR(Stale Cookie)][DATA] desde una de sus direcciones no principales, el procesamiento del chunk ERROR toma la ruta no fatal de reintento por cookie obsoleta sctp_sf_do_5_2_6_stale(), que encola SCTP_CMD_DEL_NON_PRIMARY mientras mantiene viva la asociación. sctp_cmd_del_non_primary() elimina todos los transportes no principales, incluido el mismo transporte por el que llegó este paquete, que todavía está referenciado por la búsqueda de recepción y es compartido por todos los chunks del paquete mediante chunk->transport. sctp_assoc_rm_peer() sí redirige asoc->peer.last_data_from fuera del transporte eliminado, pero justo después el chunk DATA agrupado hace que sctp_assoc_bh_rcv() vuelva a registrar asoc->peer.last_data_from = chunk->transport de forma incondicional, deshaciendo la redirección con el transporte recién eliminado. Una vez procesado el paquete, se libera la referencia de recepción y el transporte se libera mediante RCU, mientras la asociación sobreviviente conserva el puntero colgante last_data_from. Un FWD-TSN posterior (o el temporizador de SACK diferido) hace que sctp_gen_sack() lo desreferencie (->param_flags y otros), y sctp_make_sack()/sctp_outq_select_transport() pueden escribir en el objeto liberado y enlazarlo en la lista de transportes activa. Se trata de un uso después de liberar memoria (use-after-free) que puede provocar cualquier par SCTP malicioso (o un usuario local sin privilegios que actúe como tal) sin requerir capacidades: 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 Cabe señalar que el commit 03a9d10ecf71 ("sctp: drop a chunk if its transport was removed") solo cubre la ventana entre la búsqueda de recepción y el procesamiento del chunk (por ejemplo, un ASCONF DEL-IP en carrera con el backlog del socket); aquí el transporte se elimina *mientras* se procesa el paquete, por un chunk anterior del mismo paquete, por lo que el descarte en sctp_inq_push() no alcanza esta ruta. Se verificó con el reproductor agrupado [ERROR(Stale Cookie)][DATA] + FWD-TSN: el informe de KASAN anterior sigue apareciendo con ese commit aplicado y desaparece con este parche encima. Se corrige descartando el resto del paquete en esta ruta, según lo sugerido por Xin. Después de que el ERROR de cookie obsoleta devuelve la asociación a COOKIE-WAIT y elimina los transportes no principales, los chunks restantes del paquete solo pueden ejecutarse contra el handshake reiniciado mientras referencian el transporte de llegada eliminado a través de chunk->transport: además del registro de last_data_from mencionado, sctp_cmd_setup_t2() y los constructores de respuestas sctp_make_*() también copiarían ese puntero en estado con la vida útil de la asociación que sctp_assoc_rm_peer() ya ha saneado. Se deja que el par los retransmita, en línea con lo que hace sctp_inq_push() con los chunks cuyo transporte se eliminó antes del procesamiento.
Qué hacer
Revisa si usas el producto afectado y en qué versión, y aplica la actualización o la mitigación que indique el aviso del fabricante. CISA no ha confirmado que se esté explotando; si eso cambia, esta ficha pasa a «explotada» y te avisamos en el boletín.
Versiones afectadas
- Linux Afectadas: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 y anteriores a c0af3fd150fdc43821df3bb77e5ec74faf4dfc7a · 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 y anteriores a 854c053c71459f8db7ef07db9cfa4eec5f5206f2 · 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 y anteriores a 965e21ea16acb394d5e5801998ca9b0adc669665 · 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 y anteriores a 1cd246b214dc9acf4e2f11d58c035e1e672fe7d2 · 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 y anteriores a d68c9287b3ca0d6faadc61fbcb18d1a6b5493321 · 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 y anteriores a ec23855274a73906b02f0d124fefd9cb3c008b1d · 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 y anteriores a 6df536c5acbc0abd6f119d02e24f4a2ed97707f4 · 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 y anteriores a 4498467a8af06cfa3d71cb04bd7c4170dec8f449
- Linux Afectadas: 2.6.12 No afectadas: 5.10.271 · 5.15.222 · 6.1.189 · 6.6.158 · 6.12.112 · 6.18.55
Según el registro de la vulnerabilidad en CVE.org, tal como lo publicó el fabricante. Confirma tu versión exacta en el aviso del fabricante.
Referencias
- Referencia en git.kernel.orggit.kernel.org/stable/c/c0af3fd150fdc43821df3bb77e5ec74faf4dfc7a
- Referencia en git.kernel.orggit.kernel.org/stable/c/854c053c71459f8db7ef07db9cfa4eec5f5206f2
- Referencia en git.kernel.orggit.kernel.org/stable/c/965e21ea16acb394d5e5801998ca9b0adc669665
- Referencia en git.kernel.orggit.kernel.org/stable/c/1cd246b214dc9acf4e2f11d58c035e1e672fe7d2
- Referencia en git.kernel.orggit.kernel.org/stable/c/d68c9287b3ca0d6faadc61fbcb18d1a6b5493321
- Referencia en git.kernel.orggit.kernel.org/stable/c/ec23855274a73906b02f0d124fefd9cb3c008b1d
- Referencia en git.kernel.orggit.kernel.org/stable/c/6df536c5acbc0abd6f119d02e24f4a2ed97707f4
- Referencia en git.kernel.orggit.kernel.org/stable/c/4498467a8af06cfa3d71cb04bd7c4170dec8f449
Ver el texto original en inglés (CVE.org)
sctp: discard the rest of the packet on a stale-cookie error
In the Linux kernel, the following vulnerability has been resolved: sctp: discard the rest of the packet on a stale-cookie error When an association is in COOKIE-ECHOED state and the peer sends a bundled [ERROR(Stale Cookie)][DATA] packet from one of its non-primary addresses, processing the ERROR chunk takes the non-fatal stale-cookie retry path sctp_sf_do_5_2_6_stale(), which queues SCTP_CMD_DEL_NON_PRIMARY while keeping the association alive. sctp_cmd_del_non_primary() removes every non-primary transport - including the very transport this packet arrived on, which is still referenced by the receive lookup and shared by all chunks of the packet via chunk->transport. sctp_assoc_rm_peer() does redirect asoc->peer.last_data_from away from the removed transport, but right afterwards the bundled DATA chunk makes sctp_assoc_bh_rcv() re-register asoc->peer.last_data_from = chunk->transport unconditionally, undoing the redirection with the just-removed transport. Once the packet is done, the receive reference is dropped and the transport is RCU-freed, while the surviving association keeps the dangling last_data_from. A later FWD-TSN (or the delayed SACK timer) makes sctp_gen_sack() dereference it (->param_flags and friends), and sctp_make_sack()/sctp_outq_select_transport() may write to the freed object and link it into the live transport list. This is a use-after-free triggerable by any malicious SCTP peer (or a local unprivileged user acting as one) with no capabilities required: 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 Note that commit 03a9d10ecf71 ("sctp: drop a chunk if its transport was removed") only covers the window between the receive lookup and the chunk processing (e.g. an ASCONF DEL-IP racing the socket backlog); here the transport is removed *while* the packet is being processed, by an earlier chunk of the same packet, so the drop in sctp_inq_push() does not reach this path. Verified with the bundled [ERROR(Stale Cookie)][DATA] + FWD-TSN reproducer: the KASAN report above still fires with that commit applied, and is gone with this patch on top. Fix it by discarding the rest of the packet on this path, as suggested by Xin. After the stale-cookie ERROR has sent the association back to COOKIE-WAIT and removed the non-primary transports, the remaining chunks of the packet can only run against the restarted handshake while referencing the removed arrival transport through chunk->transport: besides the last_data_from registration above, sctp_cmd_setup_t2() and the sctp_make_*() reply builders would also copy that pointer into association-lifetime state that sctp_assoc_rm_peer() has already sanitized. Let the peer retransmit them, in line with what sctp_inq_push() does for chunks whose transport was removed before processing.