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

[Valery Ushakov]

On Wed, Jan 22, 2014 at 09:30:33 +0100, Per Ekman wrote:

> Ping? I would have entered this as a bug but I could not
> get the Savannah login to work.
> 
> Per Ekman <address@hidden> writes:
> 
> > I've observed the following with the rawapi in lwip 1.4.1 :
> >
> > - tcp_input():356 calls the application receive callback on a pcb
> > which is in CLOSE_WAIT.

How does this happen (I haven't traced all state transitions in the
code)?  An incoming segment for a pcb in ESTABLISHED state that
contains both data and FIN, right?

tcp_process() moves pcb to CLOSE_WAIT and tcp_input() calls receive
callback on the pcb passing the data.

tcp_input() will indicate transition to CLOSE_WAIT (incoming FIN) by
calling receive callback with NULL pbuf later on.


> > - 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

So the callback hasn't acknowledged the data with tcp_recved() before
calling tcp_close(), right?


> > - 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.

If the close is really intended to be a reaction on incoming FIN,
callback should wait until it's called with NULL pbuf (not snoop on
the pcb state, as my guess would be :).  It should also acknowledge
incoming data.  If the close is indeed intended to abort the
connection, then callback should return ERR_ABRT.

Do I miss something in this picture?  TCP state transitions always
make my head reel.

-uwe