[En-Nut-Discussion] FYI: Integer overflow in tcp socket write function fixed
ole.reinhardt at embedded-it.de
Wed Sep 30 10:43:06 CEST 2015
Am 30.09.2015 09:40, schrieb Harald Kipp:
> On 29.09.2015 22:29, Ole Reinhardt wrote:
>> I fixed another long time hidden bug in the TCP socket code.
>> Both functions suffered from size calculations based on uint16_t
>> variables, which resulted in integer overflows, when calling these
>> functions with buffer sizes > 64K.
> Actually this is not a bug, but a missing documentation item. I assume,
> that there are more routines in Nut/OS, where I/O buffers are limited to
> 32k (not 64k). In most cases this is more than sufficient.
Ok :) For me it's more a bug, as I would expect fwrite and similar
functions to correctly return the number of written bytes in any case.
Independant how large the buffer really is.
So in case the I/O buffer that a function can handle is limited to 32K
it should send out 32K and then return this value, but not the one given
as length parameter.
Currently NutTcpDeviceWrite() simply returns the size passed as
parameter on -1 in case of an error.
This brings me to another point:
In my experience, most users do not use the I/O routines correctly and
simply do not handle the return value. In best case, it is checked for a
negative value (error check), but in most cases no one checks, if the
correct amount of data was written.
And so we do in Nut/OS :)
lua/liolib.c: g_write(), Here the return value is checked, but no retry
is implemented, if the first fwrite was not
able to send the complete buffer.
And some more.
kernel concepts GmbH Tel: +49-271-771091-14
Sieghuetter Hauptweg 48 Mob: +49-177-7420433
More information about the En-Nut-Discussion