Title: Linux, Description: En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:

net/smc: corrige la desreferencia de NULL y el UAF en smc_tcp_syn_recv_sock()

Syzkaller informó un pánico en smc_tcp_syn_recv_sock() [1].

smc_tcp_syn_recv_sock() se llama en la ruta de recepción TCP (softirq) a través de icsk_af_ops -> syn_recv_sock en el clcsock (socket de escucha TCP). Lee sk_user_data para obtener el puntero smc_sock. Sin embargo, cuando el socket de escucha SMC se está cerrando concurrentemente, smc_close_active() establece clcsock -> sk_user_data en NULL bajo sk_callback_lock, y luego el propio smc_sock puede ser liberado a través de sock_put() en smc_release().

Esto lleva a dos problemas:

1) Desreferencia de puntero NULL: sk_user_data es NULL cuando se accede.
2) Uso después de liberación: sk_user_data se lee como no-NULL, pero el smc_sock es liberado antes de que se acceda a sus campos (por ejemplo, queued_smc_hs, ori_af_ops).

La ventana de carrera se ve así (el fallo de syzkaller [1] se activa a través de la ruta de la cookie SYN: tcp_get_cookie_sock()  ->  smc_tcp_syn_recv_sock(), pero la ruta normal de tcp_check_req() tiene la misma carrera):

  CPU A (softirq)              CPU B (contexto de proceso)

  tcp_v4_rcv()
    TCP_NEW_SYN_RECV:
    sk = req -> rsk_listener
    sock_hold(sk)
    /* Sin bloqueo en el oyente */
                               smc_close_active():
                                 write_lock_bh(cb_lock)
                                 sk_user_data = NULL
                                 write_unlock_bh(cb_lock)
                                 ...
                                 smc_clcsock_release()
                                 sock_put(smc -> sk) x2
                                    ->  ¡smc_sock liberado!
    tcp_check_req()
      smc_tcp_syn_recv_sock():
        smc = user_data(sk)
           ->  NULL o colgante
        smc -> queued_smc_hs
           ->  ¡fallo!

Tenga en cuenta que el clcsock y el smc_sock son dos objetos independientes con recuentos de referencia separados. La pila TCP mantiene una referencia en el clcsock, lo que lo mantiene vivo, pero esto NO evita que el smc_sock sea liberado.

Solucione esto utilizando RCU y refcount_inc_not_zero() para acceder de forma segura a smc_sock. Dado que smc_tcp_syn_recv_sock() se llama en la ruta del handshake de tres vías de TCP, tomar read_lock_bh en sk_callback_lock es demasiado pesado y no sobreviviría a un ataque de inundación SYN. Usar rcu_read_lock() es mucho más ligero.

- Establezca SOCK_RCU_FREE en el socket de escucha SMC para que la liberación de smc_sock se posponga hasta después del período de gracia de RCU. Esto garantiza que la memoria sigue siendo válida cuando se accede dentro de rcu_read_lock().
- Use rcu_read_lock() para proteger la lectura de sk_user_data.
- Use refcount_inc_not_zero(&smc -> sk.sk_refcnt) para fijar el smc_sock. Si el recuento de referencias ya ha llegado a cero (ruta de cierre completada), devuelve falso y salimos de forma segura.

Nota: smc_hs_congested() tiene una lectura similar sin bloqueo de sk_user_data sin rcu_read_lock(), pero solo verifica si es NULL y accede al smc_hs_wq global, nunca desreferenciando ningún campo de smc_sock, por lo que no se ve afectado.

El reproductor fue verificado con inyección de mdelay y smc_run, el problema ya no ocurre con este parche aplicado.

[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9