Re: [lwip-devel] Bad memory ref in tcp_input() after tcp_close()

[Valery Ushakov]

On Thu, Jan 23, 2014 at 11:09:42 +0100, Per Ekman wrote:

> Valery Ushakov <address@hidden> writes:
> 
> > On Wed, Jan 22, 2014 at 09:30:33 +0100, Per Ekman wrote:
> >
> >> > - The application receive callback calls tcp_close()
> >> >
> >> > - tcp_close_shutdown() sees that the pcb is in CLOSE_WAIT and that
> >> >   pcb->rcv_wnd != TCP_WND which causes it to free the pcb
> >> >   and return ERR_OK
[...]
> >> > - The application receive callback returns ERR_OK to tcp_input()
> >> >   which proceeds to dereference the freed pcb and passes it to
> >> >   tcp_output() (tcp_input():386)
> >
> > Arguably, callback must not return ERR_OK in this case, since by
> > calling tcp_close() without acknowledging incoming data it effectively
> > aborts the connection.
> 
> Well, the rawapi.txt does not say this and also the comments in
> tcp_close_shutdown() states that it handles this case (by sending a
> RST). From the applications standpoint it just calls tcp_close(), not
> tcp_abort().

If callback causes RST, then ERR_ABRT must be returned from the
callback and the pcb considered dead.  This is documented for
tcp_abort(), but tcp_close() as currently implemented may effectively
do tcp_abort() internally.  The fact that tcp_close() doesn't really
tell the caller whether it has done RST or not can be considered as an
API bug.

I'm not at the moment prepared to meaningfully pursue this line of
inquiry, though.  Too much of RTFS context is unloaded.

-uwe