[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ambroz Bizjak
Subject: [lwip-devel] [bug #52112] Unavoidable hazards when calling tcp_close from callback
Date: Mon, 25 Sep 2017 14:39:06 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36


                 Summary: Unavoidable hazards when calling tcp_close from
                 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



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:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]