curl: Heap buffer overflow in TFTP when using small blksize

Summary:

With a TFTP server that does not send OACK, but instead starts anyway with first block with 512 bytes block size, the curl library fails to assume default 512 bytes blocks. Instead it detects EOF and does not return an error code. Consequence is a truncated file that is 512 bytes without any error code.

My understanding is that from the RFC, a TFTP server might ignore blksize request and anyway send the default 512 bytes block size data.

Unless an OACK is received we should assume 512 block size, whether or not a particular blocksize was requested.

This was introduced by security fix of CVE-2019-5436:
257600341 tftp: use the current blksize for recvfrom()

Potential Fix

We could revert 2576003415625d7b5f0e390902f8097830b82275 and instead malloc the receive buffer for at least 512 bytes, or for the requested blksize if it is bigger. That would address the issue being reported and also the CVE-2019-5436.

Steps To Reproduce:

1. Use a TFTP server that does not send OACK in response of a particular blksize request, but instead sends directly the first block, of default size (512B).
2. Run curl asking for a >512 bytes block size like:
   curl --tftp-blksize 8192 tftp://9.1.9.1/data.bin --output data.bin
3. echo $? is 0 and file size is 512 bytes

Comment

Not too sure about the Weakness identification and/or Severity, reporting it here since it was introduced by a CVE fix.

Impact

File truncation without ‘curl’ returning any error code.