In packet_send2, rather than issue two separate buffer_prepend_data calls
(each of which may entail realloc + memmove + memcpy), elide the prepend
work into a single buffer_prepend_data: the header information is computed
locally, and a single 5 byte prepend operation is now done instead of
prepending 1, then 4 bytes.
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
(cherry picked from commit aa05248ca8)
Conflicts:
src/packet.c
After discussion with Aris and it was not obvious enough to understand
the issue we decided to refactor it.
Reviewd-by: Aris Adamantiadis <aris@0xbadc0de.be>
If we receive a packet of length exactly blocksize, then
packet_decrypt gets called on a buffer of size 0. The check at the
beginning of packet_decrypt indicates that the function should be
called on buffers of at least one blocksize, though the check allows
through zero length. As is packet_decrypt can return -1 when len is 0
because malloc can return NULL in this case: according to the ISO C
standard, malloc is free to return NULL or a pointer that can be freed
when size == 0, and uclibc by default will return NULL here (in
"non-glibc-compatible" mode). The net result is that when using
uclibc connections with libssh can anomalously fail.
Alternatively, packet_decrypt (and probably packet_encrypt for
consistency) could be made to always succeed on len == 0 without
depending on the behavior of malloc.
Thanks to Josh Berlin for bringing conneciton failures with uclibc to
my attention.
Signed-off-by: Alan Dunn <amdunn@gmail.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
