Message 192778 - Python tracker

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?

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?

History
Date	User	Action	Args
2013-07-09 20:52:00	vstinner	set	recipients: + vstinner, amaury.forgeotdarc, pitrou, christian.heimes, Tom.van.Leeuwen, noxiouz
2013-07-09 20:52:00	vstinner	set	messageid: <1373403120.22.0.187923617381.issue18100@psf.upfronthosting.co.za>
2013-07-09 20:52:00	vstinner	link	issue18100 messages
2013-07-09 20:52:00	vstinner	create