[lwip-devel] [bug #50276] tcp: fix accept event on closed listening PCBs

[David van Moolenbroek]

Follow-up Comment #2, bug #50276 (project lwip):

Hmm well, even though I stand by this patch and I still believe it is an
improvement, I feel obliged to add the following. The same crash happened
again, and this time I managed to reproduce it. As it turns out, the reason is
that with the events API, events other than ACCEPT are also fired on
connections that are arriving, but have not yet been accepted, on a listening
socket. That is, connections in SYN_RCVD state. Such connections may see not
only ACCEPT events, but also POLL and ERR events. Those events are obviously
not interesting to the higher layer, but unlike with the callback API, where
no callback functions will have been set for them yet, the event API will pass
them to the event handler anyway.

Since the PCBs of such connections will have the callback_arg copied from the
listening PCB, and this argument is (I assume) typically used to point to a
socket structure with additional data, this poses a major problem: *if* there
is a chance that the listening socket has been closed already (simply due to
an application close() call or so), then the callback_arg of the arriving PCB
will effectively be a dangling pointer. For POLL events on the SYN_RCVD
connection, this is not a problem, because in that case, the event handler can
check whether the PCB's state is SYN_RCVD and the listener field is NULL
(meaning the listening socket has disappeared), and simply disregard the event
in that case. For ERR events on the SYN_RCVD connection however, the PCB is
already gone, and all the event handler has to go on, is a dangling pointer to
what used to be the listening PCB.

This is the current situation, and as I see it, there are only two possible
ways forward:
1) add checks for state==SYN_RCVD && listener==NULL to the POLL and ERR event
triggers in the lwIP core TCP code to make sure such events are not passed to
the event handler in that case, or,
2) deem the entire event API suitable only for use cases where listening
sockets, if any, are never closed, i.e. only for very basic uses of lwIP.

I'm not sure what is the best option here. I think #1 might be helpful for all
use cases, including the "basic" use, but I think #2 would be fine as well.
Either way, I caved and switched over my own implementation to the callback
API after all, just to be on the safe side at least for now.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?50276>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/