Closed agronholm closed 10 months ago
I fuzzed this branch a bit, and it produced the following crash:
I've attached the crash here: crash-54a4c03551e10f514542bdf35c00142e617b1ff1.txt
Would you be interested in having your project be a part of OSS-Fuzz? That could help with automatically finding crashes and bugs for you. I could take care of adding it as a new project - all I'd need is a primary contact email address.
Sounds okay. Is it comparable with Hypothesis?
And my primary contact address is alex.gronholm@nextday.fi.
And my primary contact address is alex.gronholm@nextday.fi.
Hmm, the adding new projects docs say that a Google account is required. Is that email address connected to a Google account by chance?
Fuzzing testing is similar in some ways to Hypothesis. OSS-Fuzz is a project by Google to provide free compute cycles to fuzz OSS software. For more information on fuzzing, I'd recommend starting here.
Yes, that's associated with a Google account.
I've attached the crash here: crash-54a4c03551e10f514542bdf35c00142e617b1ff1.txt
What do I do with this if I want to reproduce the crash?
I've attached the crash here: crash-54a4c03551e10f514542bdf35c00142e617b1ff1.txt
What do I do with this if I want to reproduce the crash?
I tested it out like this:
$ python -m cbor2.tool -p crash-54a4c03551e10f514542bdf35c00142e617b1ff1.txt
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "lib/python3.11/site-packages/cbor2/tool.py", line 225, in <module>
main()
File "lib/python3.11/site-packages/cbor2/tool.py", line 208, in main
objs = (load(infile, tag_hook=my_hook),)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
MemoryError
Alright, I was able to reproduce the crash here. I think I need to start fuzzing the code before I push anything to master.
Looks like this is just another case of allocating a huge amount of memory (4629771061636907009) bytes, but this triggers a MemoryError
with the Python implementation too.
Turns out that the problem wasn't triggered with a BytesIO
instance, but it is triggered with a real open file.
All other Python CBOR implementations I tested with also raised a MemoryError
when trying to decode input like that.
I have a fix that avoids MemoryError
in both implementations, but it introduced a new bug on the C side that I'm still tracking down.
Alright, what's left now is to fuzz this branch before I merge.
I'm not getting any MemoryError
anymore with fuzzing. Would you like to verify?
I'm not getting any
MemoryError
anymore with fuzzing. Would you like to verify?
I found another crash with the following file: crash-c528afcec87be909de91322a14693702fd1d44a0.txt
I think I'm correctly fuzzing this branch, but I'm not sure. Are you able to reproduce the crash?
Yeah, I can reproduce it. Looking into it now.
No, wait, I forgot to recompile after switching branches. I'm getting this instead now: _cbor2.CBORDecodeEOF: premature end of stream (expected to read 65536 bytes, got 509 instead)
. This is the exception we should be getting, yes?
I'm not seeing anything bad in this branch after the commit I just pushed a little while ago, so I'm merging it.
Looks like the OSS-Fuzz PR went through: https://github.com/google/oss-fuzz/pull/11444 🎉
Relates to #198.