forked from Minki/linux
944e594cfa
When a userspace application starts a blocking connect(), a CALL REQUEST is sent, the t21 timer is started and the connect is waiting in x25_wait_for_connection_establishment(). If then for some reason the t21 timer expires before any reaction on the assigned logical channel (e.g. CALL ACCEPT, CLEAR REQUEST), there is sent a CLEAR REQUEST and timer t23 is started waiting for a CLEAR confirmation. If we now receive a CLEAR CONFIRMATION from the peer, x25_disconnect() is called in x25_state2_machine() with reason "0", which means "normal" call clearing. This is ok, but the parameter "reason" is used as sk->sk_err in x25_disconnect() and sock_error(sk) is evaluated in x25_wait_for_connection_establishment() to check if the call is still pending. As "0" is not rated as an error, the connect will stuck here forever. To fix this situation, also check if the sk->sk_state changed form TCP_SYN_SENT to TCP_CLOSE in the meantime, which is also done by x25_disconnect(). Signed-off-by: Martin Schiller <ms@dev.tdt.de> Link: https://lore.kernel.org/r/20220805061810.10824-1-ms@dev.tdt.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|---|---|---|
| .. | ||
| af_x25.c | ||
| Kconfig | ||
| Makefile | ||
| sysctl_net_x25.c | ||
| x25_dev.c | ||
| x25_facilities.c | ||
| x25_forward.c | ||
| x25_in.c | ||
| x25_link.c | ||
| x25_out.c | ||
| x25_proc.c | ||
| x25_route.c | ||
| x25_subr.c | ||
| x25_timer.c | ||