[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] use-after-free caused by tcp_input_delayed_close
From: |
Douglas |
Subject: |
Re: [lwip-devel] use-after-free caused by tcp_input_delayed_close |
Date: |
Sun, 21 Apr 2019 01:07:02 +1000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
Hi,
Might the following guard in lwip_netconn_do_close() protect the
shutdown() call? "if ((msg->conn->pcb.tcp != NULL)"
The close() path appears to use lwip_netconn_do_delconn() which has the
following guard "if (msg->conn->pcb.tcp != NULL)"
It looks like err_tcp() is called when the other end closes the
connection, from tcp_input_delayed_close(), and this function sets
conn->pcb.tcp to NULL, and that NULL should protect later calls to
shutdown() which would return ERR_CONN, and to close().
Would you be able to check this, see if these guards are working when
this can be reproduced? Can you get a better idea of the failure path.
Douglas
On 1/24/19 8:01 PM, Michael Zimmermann wrote:
> Hi,
>
> I'm running a tcp server using LWIP and upon termination of the
> connection, both sides do a "shutdown(sock, SHUT_WR)", wait for recv to
> return 0, call "shutdown(sock, SHUT_RDWR)", call "close(sock)".
>
> The bug occurs in form of a race condition:
> - the lwip server calls SHUT_WR
> - the client calls SHUT_WR, once lwip saw this, it sets TF_RXCLOSED in
> "pcb->flags"
> - the client closes the connection, lwip sees this, adds TF_CLOSED to
> recv_flags, and then deletes the pcb within "tcp_input_delayed_close".
>
> The problem here is that "tcp_input_delayed_close" only calls the
> "pcb->errf" callback on this condition:
> "if (!(pcb->flags & TF_RXCLOSED))"
>
> I don't really know why that was done in first place, but because of
> this, the pcb gets freed without notifying the user(which would set
> conn->pcb.tcp to NULL) in case the RX side was closed already.
>
> On the next call to shutdown or close, this results in use-after-free.
>
> I'm posting this to the mailing list first instead of the bug tracker to
> discuss the intention behind the condition and to come up with a proper
> solution.
>
> Thanks
> Michael Zimmermann
>
> IOTΛ Data Marketplace Member · MS Azure IoT Gold Partner · Apple MFi
> Developer · Bluetooth SIG · zigbee Alliance · LoRa Alliance · Thread Group
>
> grandcentrix GmbH · Holzmarkt 1 · 50676 Köln · Deutschland
> | t <https://twitter.com/grandcentrix> | f
> <https://www.facebook.com/GrandCentrix/> | in
> <https://www.linkedin.com/company/grandcentrix> | phone:
> +49-221-677-860-0 | email: address@hidden
> <mailto:address@hidden>
>
> Amtsgericht Köln | HRB 70119 | Geschäftsführer: R. Rottmann, M. Willnow
> | USt.-IdNr.: DE266333969
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-devel
>