✓ProveIt
Examples / Report #684603 Saved analysis

CVE-2019-5482: Heap buffer overflow in TFTP when using small blksize

curl · 2019-08-297.8s analysis · $0.007 in model calls

What the report claims

curl fails to return an error when a TFTP server sends a truncated 512-byte block in response to a larger blksize request, leading to a truncated output file without an error code.

Compare with curl's recorded outcome

Known vulnerability

A real vulnerability: CVE-2019-5482 TFTP small blocksize heap buffer overflow

Shown for comparison after analysis. The pipeline did not see this label.

ProveIt's finding

Needs human review

The available evidence does not settle the report. A maintainer should investigate.

Why this finding?
  • The report references a specific commit (257600341) and CVE (CVE-2019-5436) and provides concrete reproduction steps, making it plausible.
  • However, the provided curl source code only includes src/mkhelp.pl and lib/setup-os400.h — neither contains the TFTP client implementation (likely lib/tftp.c) where the flaw would reside.
  • Without the TFTP source code, no claim can be verified or contradicted against the code.
What still needs checking
  • The TFTP client source file (e.g., lib/tftp.c) from revision 0690b3330cee, particularly the recvfrom handling and block size negotiation logic modified by commit 257600341.
How this analysis ran 5 claims · 0 citations verified

Checked against curl master on 2019-08-29 (0690b3330cee). Test evaluation split. Citation verification checks that a referenced line was in the evidence; it does not prove the model interpreted it correctly.

1 · Grounding
grounded
no model · 1 references checked out, 0 did not
2 · Claims
NVIDIA-Nemotron-3-Nano-30B-A3B
5 claims · 1563 tokens · $0.0002
3 · Evidence
2 code snippets
real curl source at 0690b3330cee
4 · Judgment
Nemotron-3-Ultra-550b-a55b
3945 tokens · 5.3s · $0.0072
5 · Receipts
0 of 0 citations verified
every citation must point at code the judge was shown
Review a draft reply to the reporter

Edit and verify before sending.

Thank you for the detailed report with reproduction steps and commit reference. The provided source code snapshot does not include the TFTP implementation (lib/tftp.c) where the block size handling logic resides. Could you confirm the exact file paths involved, or would you be able to provide the relevant TFTP source sections from the revision in question? This would allow us to verify the buffer handling and error return path you describe.

Inspect all claims and source code 5 claims · 2 code excerpts

Report claims

C1flaw not verifiable

curl fails to return an error code when a TFTP server sends a block smaller than the requested blksize, resulting in a truncated file

Read the reasoning

The claim describes TFTP client behavior when handling block size negotiation. The provided source code only contains src/mkhelp.pl (a help text generator) and lib/setup-os400.h (an OS/400 recvfrom macro). The TFTP implementation (likely in lib/tftp.c) is not provided, so the claim cannot be verified against the code.

C2location not verifiable

The flaw occurs in the TFTP client implementation when handling block size negotiation and reception

Read the reasoning

The claim locates the flaw in the TFTP client implementation. The relevant TFTP source files are not included in the provided code, making verification impossible.

C3trigger not verifiable

A TFTP server that does not send OACK but sends a 512-byte block directly in response to a blksize request larger than 512

Read the reasoning

The claim describes a trigger condition involving a TFTP server behavior. The curl client code that would handle this condition (TFTP block reception logic) is not in the provided source files.

C4impact not verifiable

The file is truncated to 512 bytes and curl exits with status 0, providing no indication of the truncation

Read the reasoning

The claim describes the impact (truncated file, exit code 0). The code path producing this behavior is in the TFTP implementation, which is not provided.

C5reproduction not verifiable

Using curl with --tftp-blksize 8192 against a server that sends the first block of 512 bytes without OACK reproduces the truncation

Read the reasoning

The claim gives reproduction steps. While concrete, the code that would be exercised by these steps (TFTP client with --tftp-blksize handling) is not in the provided source.

Read the original report

Full report on HackerOne ↗

## 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.

Source code

src/mkhelp.pllines 202–220 · definition of for
202for(@out) {
203 chop;
204
205 $new = $_;
206
207 $outsize += length($new)+1; # one for the newline
208
209 $new =~ s/\\/\\\\/g;
210 $new =~ s/\"/\\\"/g;
211
212 # gcc 2.96 claims ISO C89 only is required to support 509 letter strings
213 if($outsize > 500) {
214 # terminate and make another fputs() call here
215 print ", stdout);\n fputs(\n";
216 $outsize=length($new)+1;
217 }
218 printf("\"%s\\n\"\n", $new);
219
220}
lib/setup-os400.hlines 213–213 · definition of recvfrom
213#define recvfrom Curl_os400_recvfrom