[En-Nut-Discussion] FYI: Integer overflow in tcp socket write function fixed

[Ole Reinhardt]

Hi Harald,

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 :)

For example:

pro/httpd.c: NutHttpProcessFileRequest()
pro/asp.c:   NutHttpProcessAsp()
pro/ssi.c:   NutSsiProcessFile()
pro/uhttp/os/nut/streamio.c: s_vputs

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.

Best regards,

Ole

-- 
kernel concepts GmbH            Tel: +49-271-771091-14
Sieghuetter Hauptweg 48         Mob: +49-177-7420433
D-57072 Siegen
http://www.embedded-it.de
http://www.kernelconcepts.de