Message192778
| Author |
vstinner |
| Recipients |
Tom.van.Leeuwen, amaury.forgeotdarc, christian.heimes, noxiouz, pitrou, vstinner |
| Date |
2013年07月09日.20:52:00 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1373403120.22.0.187923617381.issue18100@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> ssize_t send(int socket, const void *buffer, size_t length, int flags);
Oh, I didn't notice that. I hope that the result always fit in a ssize_t. If it is not the case, it is probably a bug in the kernel. An example of such bug:
http://xorl.wordpress.com/2009/04/10/cve-2009-1265-linux-kernel-rosex25netrom-integer-overflows/
On Solaris, read(), send() and probably other functions return EINVAL if input length argument overflows a ssize_t. We may be extra-safe by truncating the length to PY_SSIZE_T_MAX. But I would appreciate a test on Linux and Solaris with such huge values. Which kind of socket should be used to test such buffer? |
|