Repository navigation
Continuous fuzzing with OSS-Fuzz? #346
Description
Hi! I'd like to help set up continuous fuzzing in OSS-Fuzz for TinyCBOR. Memory-safety bugs keep being reported here (e.g. #258, #259, #318, #328), often found by people running their own private fuzzers: with OSS-Fuzz they would be found early and reported privately to you.
I know Qt bundles a copy of TinyCBOR and Qt is in OSS-Fuzz, but that only covers the paths Qt uses, on Qt's copy. I'd write libFuzzer harnesses for TinyCBOR's own API: the parser and cbor_value_validate, the CBOR-to-JSON conversion, json2cbor and the encoder (in a fuzz/ folder here), plus the OSS-Fuzz build files.
The only thing needed from you is a maintainer listed as the contact for the private bug reports. Would that be welcome? If you'd prefer something lighter, I could set up ClusterFuzzLite in your CI instead.
I'd write the harnesses with the help of Claude Code, but I'll review and test everything myself (with ASan/UBSan) and can explain any part of it.
Activity
thiagomacieira commentedon Oct 26, 2026
Hello @Topogamer0
Thank you for the offer, I'd like to take you up on it. You can use my work email as the private contact (you can see in commit headers). I do not consider json2cbor to be security-relevant (it's just an example) and therefore fuzzing it is not necessary.
Topogamer0 commentedon Oct 26, 2026
Thank you! I'll leave json2cbor out and focus on the library itself: the parser, cbor_value_validate, the CBOR-to-JSON and pretty-printing conversions, and the encoder.
One question before I start: TinyCBOR uses assert() in a few places (#328). For the fuzzers, would you prefer them built with NDEBUG (so only real memory errors are reported), or with asserts enabled, treating a failed assert as a bug?
I'll first open a PR here with the harnesses in a fuzz/ folder, then the OSS-Fuzz one with you as the primary contact.
thiagomacieira commentedon Oct 26, 2026
A failed
assert()is a SW bug in the application (in this case, the fuzzer harness). I don't know how you handle that with OSS-Fuzz; ideally you'd first check an assert-enabled non-ASan run with the content to see if you have a bug in the harness, and only after that use the ASan run to validate.Topogamer0 commentedon Oct 26, 2026
Thanks, that’s what I did: I first ran the fuzzers with asserts enabled and no sanitizers, fixed the harness bugs until no assert fired, and only then ran them with ASan/UBSan. The PR is #350.