Vulnerabilidad en kernel de Linux (CVE-2024-26921)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: inet: inet_defrag: evita la liberación de sk mientras aún está en uso ip_local_out() y otras funciones pueden pasar skb->sk como argumento de función. Si el skb es un fragmento y el reensamblaje ocurre antes de que regrese dicha llamada a la función, el sk no debe liberarse. Esto afecta a los fragmentos de skb reensamblados mediante netfilter o módulos similares, por ejemplo, openvswitch o ct_act.c, cuando se ejecutan como parte de la canalización tx. Eric Dumazet hizo un análisis inicial de este error. Citando a Eric: Llamar a ip_defrag() en la ruta de salida también implica skb_orphan(), lo cual tiene errores porque la ruta de salida depende de que sk no desaparezca. Un parche antiguo relevante sobre el problema era: 8282f27449bf ("inet: frag: Siempre skbs huérfanos dentro de ip_defrag()") [..] net/ipv4/ip_output.c depende de que skb->sk esté configurado, y probablemente en un inet socket, no uno arbitrario. Si dejamos el paquete huérfano en ipvlan, las cosas posteriores como el programador de paquetes FQ no funcionarán correctamente. Necesitamos cambiar ip_defrag() para usar skb_orphan() solo cuando sea realmente necesario, es decir, siempre que se vaya a usar frag_list. Eric sugirió guardar sk en la cola de fragmentos e hizo un parche inicial. Sin embargo, hay un problema con esto: si skb se vuelve a fragmentar inmediatamente después, ip_do_fragment() copiará head->sk a los nuevos fragmentos y configurará el destructor en sock_wfree. OIA, no tenemos más remedio que arreglar la contabilidad de sk_wmem para reflejar el skb completamente reensamblado; de lo contrario, wmem se desbordará. Este cambio mueve al huérfano hacia el núcleo, hasta el último momento posible. Como ip_defrag_offset tiene un alias con el miembro sk_buff->sk, debemos mover el desplazamiento a FRAG_CB; de lo contrario, skb->sk será golpeado. Esto permite retrasar el huérfano el tiempo suficiente para saber si el skb debe estar en cola o si el skb está completando la cola de reasm. En el primer caso, las cosas funcionan como antes, skb queda huérfano. Esto es seguro porque skb se pone en cola/se roba y no continúa más allá del motor de reasm. En el último caso, robaremos la referencia skb->sk, la volveremos a adjuntar al skb principal y arreglaremos la contabilidad de wmem cuando inet_frag infle el tamaño verdadero.