How it was found

libcurl on commit 3ee1d3b573e6ea36fb478dbd0d9913483b900928 contains a vulnerability in its TFTP implementation that can cause curl or a libcurl-user to send heap memory beyond the bounds of an allocated chunk to a malicious TFTP server.

The vulnerability lies in lib/tftp.c, in function tftp_send_first() on line 467:

if(strlen(filename) > (state->blksize - strlen(mode) - 4)) {
  // [...]
}

curl_msnprintf((char *)state->spacket.data + 2,
                state->blksize,
                "%s%c%s%c", filename, '\0', mode, '\0');
sbytes = 4 + strlen(filename) + strlen(mode);

// [...]

senddata = sendto(state->sockfd, (void *)state->spacket.data,
                  (SEND_TYPE_ARG3)sbytes, 0,
                  CURL_SENDTO_ARG5(&remote_addr->curl_sa_addr),
                  (curl_socklen_t)remote_addr->addrlen);

If curl is invoked with --tftp-no-options or a libcurl-user sets CURLOPT_TFTP_NO_OPTIONS to 1, a malicious TFTP server can cause an integer underflow in line 467 that disables the bounds check for strlen(filename). If the mode stays the default "octet" and the server communicates a minimum block size of 8 then line 467 becomes

if(strlen(filename) > (8 /* state->blksize */ - 5 /* strlen(mode) */ - 4)) {

leading to an integer underflow such that the condition becomes false. After that, sbytes can have any value depending on the length of filename and the following sendto() call may send out-of-bounds data.

Impact

I think it is pretty clear that this is at most a LOW severity vulnerabiliy. The preconditions to exploit the vulnerability are pretty strict and even then it only leads to a leak of memory contents.