fqzcomp_qual_fuzzrt.c and tokenise_name3_fuzzrt.c write past their buffers
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 88/100
Research direction
Read tests/fqzcomp_qual_fuzzrt.c around lines 72-79 and 105, and tests/tokenise_name3_fuzzrt.c around lines 61-73. Check the harness behavior with inputs larger than 5000 bytes and an 8192-byte input of As, preferably under AddressSanitizer. Done when neither harness writes out of bounds and rejects or safely handles those inputs.
Written by the indexing model from the issue text.
Description
Two of the round-trip fuzz harnesses in tests/ write past fixed-size buffers on large inputs (at c442bd7):
- tests/fqzcomp_qual_fuzzrt.c#L72-L79: the third mode calls
fake_slice(in_size, in_size), which writes one entry per input byte intoslice_len[MAX_REC]andslice_flags[MAX_REC](MAX_REC is 5000). Nothing checks the size. A 5001-byte input gives a global-buffer-overflow under ASan, andindex 5000 out of bounds for type 'unsigned int[5000]'at line 76 under-fsanitize=undefined. A build with only-fsanitize=fuzzersegfaults on a 6000-byte input. - tests/tokenise_name3_fuzzrt.c#L61-L73:
in2is 8192 bytes and inputs of up to 8192 bytes are accepted, but line 73 then appends a nul. An 8192-byte input whose last byte is above'\n', such as 8192 bytes ofA, writesin2[8192](a stack-buffer-overflow under ASan).
The comment in tokenise_name3_fuzzrt.c says 4096 is the libFuzzer default size limit, but that does not prevent this. Without -max_len, libFuzzer picks the limit from the corpus (https://llvm.org/docs/LibFuzzer.html#options), so a 6000-byte seed raises it to 6000. Running the binary on a single file passes the whole file.
A possible fix is below. Returning -1 keeps the input out of the corpus (https://llvm.org/docs/LibFuzzer.html#rejecting-unwanted-inputs), as tokenise_name3_fuzzrt.c already does for inputs over 8192 bytes.
--- a/tests/fqzcomp_qual_fuzzrt.c
+++ b/tests/fqzcomp_qual_fuzzrt.c
@@ -105,2 +105,6 @@ int LLVMFuzzerTestOneInput(uint8_t *in, size_t in_size) {
+ // fake_slice() may need one slice_len[] entry per input byte
+ if (in_size > MAX_REC)
+ return -1;
+
int mode = 0;
--- a/tests/tokenise_name3_fuzzrt.c
+++ b/tests/tokenise_name3_fuzzrt.c
@@ -60,4 +60,4 @@ int LLVMFuzzerTestOneInput(const uint8_t *in, size_t in_sz) {
int level, arith;
- char in2[8192];
+ char in2[8192+1]; // +1 for the nul added below
// 4096 is default max size for libfuzzer anyway
This issue was written by an AI model (Claude Opus 5.5, Anthropic). I can open a PR with the fix.
- Dominant language
- C
- Stars
- 40
- Forks
- 20
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 4 days
-
Difficulty 2/5 Half a day Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
enhancement help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
kabirvashisht4-glitch/Vet#22 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100