[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory

View: New views

6 Messages — Rating Filter: Alert me

	[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory by Evgenii Philippov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message URL: <http://savannah.nongnu.org/bugs/?27871> Summary: Calling tcp_abort() in recv callback can lead to accessing unallocated memory Project: lwIP - A Lightweight TCP/IP stack Submitted by: goldsimon Submitted on: Fr 30 Okt 2009 17:52:55 GMT Category: TCP Severity: 3 - Normal Item Group: Faulty Behaviour Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Planned Release: lwIP version: 1.3.1 _______________________________________________________ Details: This isn't new but has been in there for a while: When working on the raw api httpd, I found tcp_abort is called within the recv-callback (e.g. in an error state or when there's a second request to one pcb which thinks it's already closed). What I want to achieve is to force-close the pcb in this case resulting in an ACK. For this, I call tcp_abort and return ERR_ABRT. However, the code calling TCP_EVENT_RECV() not prepared for this: since tcp_abort() deallocates the pcb, and the code calling TCP_EVENT_RECV() accesses the pcb after that call, unallocated memory is accessed. In the default-recv case, this doesn't lead to a crash, as the memory is not yet used for another pcb... _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?27871> _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel
	[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory by Evgenii Philippov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #1, bug #27871 (project lwip): Wouldn't it be better to simply deprecate use of tcp_abort from applications? If one considers the usual unix behavior as an analog: an application can't abort a connection. It simply closes the socket. Once closed, the OS cleans up, sending the FIN and so forth, and can choose to reset the connection if, for example, it continues to get data destined for a socket that is no longer open. For lwip, if an application wishes to close a session, it should call tcp_close and clear its send and recv callbacks. It will not then get any further callbacks and so, as far as it's concerned, the session is gone. lwip is then responsible for cleanup: FIN-sending and/or possibly RST, as appropriate. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?27871> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel
	[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory by Evgenii Philippov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #2, bug #27871 (project lwip): That's true. But with the current layout of the headers, it's kind of hard to separate between functions for applications and internally used functions. I.e. it's not always clear what counts as API and what doesn't. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?27871> _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel
	[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory by Evgenii Philippov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #3, bug #27871 (project lwip): I don't mind applications using the raw API being able to call tcp_abort() - the raw API is by design low level, so being able to do things that applications couldn't normally do is OK. However, documenting cases like this where it is not possible to use tcp_abort() is probably wise. i.e. I think this is best solved with documentation rather than changing the code. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?27871> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel
	[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory by Evgenii Philippov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #4, bug #27871 (project lwip): > I think this is best solved with documentation rather than > changing the code. I don't know about that: tcp_abort is explicitly mentioned in rawapi.txt, so it might be used in some applications for a while now. I don't think a 'small' change in that doc file will draw much attention and thus this might be a bug in many applications. After all, from where should a raw-api application call tcp_abort() if not from one of the pcb callbacks? The only place would be a self-created timeout... _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?27871> _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel
	[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory by Evgenii Philippov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #5, bug #27871 (project lwip): I think a better change might be to disallow applications to call tcp_abort and instead process the return value of sent-, recv- and poll-callback functions to let the stack call tcp_abort when they return ERR_ABRT. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?27871> _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel

	[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory by Evgenii Philippov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message URL: <http://savannah.nongnu.org/bugs/?27871> Summary: Calling tcp_abort() in recv callback can lead to accessing unallocated memory Project: lwIP - A Lightweight TCP/IP stack Submitted by: goldsimon Submitted on: Fr 30 Okt 2009 17:52:55 GMT Category: TCP Severity: 3 - Normal Item Group: Faulty Behaviour Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Planned Release: lwIP version: 1.3.1 _______________________________________________________ Details: This isn't new but has been in there for a while: When working on the raw api httpd, I found tcp_abort is called within the recv-callback (e.g. in an error state or when there's a second request to one pcb which thinks it's already closed). What I want to achieve is to force-close the pcb in this case resulting in an ACK. For this, I call tcp_abort and return ERR_ABRT. However, the code calling TCP_EVENT_RECV() not prepared for this: since tcp_abort() deallocates the pcb, and the code calling TCP_EVENT_RECV() accesses the pcb after that call, unallocated memory is accessed. In the default-recv case, this doesn't lead to a crash, as the memory is not yet used for another pcb... _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?27871> _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel
	[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory by Evgenii Philippov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #1, bug #27871 (project lwip): Wouldn't it be better to simply deprecate use of tcp_abort from applications? If one considers the usual unix behavior as an analog: an application can't abort a connection. It simply closes the socket. Once closed, the OS cleans up, sending the FIN and so forth, and can choose to reset the connection if, for example, it continues to get data destined for a socket that is no longer open. For lwip, if an application wishes to close a session, it should call tcp_close and clear its send and recv callbacks. It will not then get any further callbacks and so, as far as it's concerned, the session is gone. lwip is then responsible for cleanup: FIN-sending and/or possibly RST, as appropriate. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?27871> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel
	[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory by Evgenii Philippov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #2, bug #27871 (project lwip): That's true. But with the current layout of the headers, it's kind of hard to separate between functions for applications and internally used functions. I.e. it's not always clear what counts as API and what doesn't. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?27871> _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel
	[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory by Evgenii Philippov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #3, bug #27871 (project lwip): I don't mind applications using the raw API being able to call tcp_abort() - the raw API is by design low level, so being able to do things that applications couldn't normally do is OK. However, documenting cases like this where it is not possible to use tcp_abort() is probably wise. i.e. I think this is best solved with documentation rather than changing the code. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?27871> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel
	[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory by Evgenii Philippov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #4, bug #27871 (project lwip): > I think this is best solved with documentation rather than > changing the code. I don't know about that: tcp_abort is explicitly mentioned in rawapi.txt, so it might be used in some applications for a while now. I don't think a 'small' change in that doc file will draw much attention and thus this might be a bug in many applications. After all, from where should a raw-api application call tcp_abort() if not from one of the pcb callbacks? The only place would be a self-created timeout... _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?27871> _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel
	[bug #27871] Calling tcp_abort() in recv callback can lead to accessing unallocated memory by Evgenii Philippov :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #5, bug #27871 (project lwip): I think a better change might be to disallow applications to call tcp_abort and instead process the return value of sent-, recv- and poll-callback functions to let the stack call tcp_abort when they return ERR_ABRT. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?27871> _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel