[lwip-devel] [bug #52112] Unavoidable hazards when calling tcp_close from callback

[Ambroz Bizjak]

URL:
  <http://savannah.nongnu.org/bugs/?52112>

                 Summary: Unavoidable hazards when calling tcp_close from
callback
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: abizjak
            Submitted on: Mon 25 Sep 2017 06:39:05 PM UTC
                Category: None
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: git head

    _______________________________________________________

Details:

Consider an application calling tcp_close from one of the PCB callbacks, where
tcp_close succeeds. In this case the application can either return ERR_ABRT or
not. It seems to me that either way things break.

- If the application does not return ERR_ABRT: There are cases where tcp_close
frees the PCB, but since the callback does not return ERR_ABRT, lwIP will try
to access the freed PCB.

- If the application returns ERR_ABRT: Consider the case where
tcp_close_shutdown called tcp_trigger_input_pcb_close(), having removed the
PCB from tcp_active pcbs but not freeing it. Since the callback returned
ERR_ABRT, tcp_input_delayed_close() is inhibited and the PCB is leaked.

My application is currently taking the second approach and I am seeing leaked
PCBs. I have not proven this is the same leak but I see no other way for a PCB
to be leaked.




    _______________________________________________________

Reply to this item at:

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

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