debrouxl
commented
4 months ago Ping ? It's been a month :)
Open debrouxl opened 5 months ago
debrouxl
commented
4 months ago Ping ? It's been a month :)
estraier
commented
4 months ago Thanks for the report (and sorry for the belated response).
Let me know of the goal of this experiment. If the process crashes during an operation setting record "A", it's natural that the record "A" is not recovered. If the process crashes during an operation setting record "B" after setting record "A", it is expected that record "A" is recovered. And, your code seems to just setting one record and the process crashes during the operation. Then, what's the expected behavior?
debrouxl
commented
4 months ago The expected behaviour is not to crash, at the very least :) While it's clear that the attempted operations, especially adding / removing / modifying records, do not have to complete successfully on a broken database, the database system must not allocate excessive amounts of memory (or abort the program through an assert trying to do that), read memory outside the allocated areas (Out Of Bound reads from stack, heap, global variables), write memory outside the allocated areas (Out Of Bounds writes, a.k.a. "memory corruption"), divide by zero, perform improper memory accesses which yield bus errors, etc. Beyond being user-unfriendly, especially a complete failure to recover a database which was already broken and usually contains data useful to the user (instead of a failure to salvage a subset of the data, when possible), the aforementioned classes of misbehaviour are vulnerabilities. Some of them (and probably all of the ones the fuzzer found in tkrzw so far) are just Denial of Service (DoS), but memory corruption often yields arbitrary code execution / remote code execution, if the corruption primitive is powerful enough and/or can be sufficiently repeated.
For the record:
Hello,
tkrzw_crashes_202404_01.tar.gz
Here's a tarball containing a set of redundant corrupted files which crash at least one of the commands listed below, and the corresponding terminal output (crashes_*.txt files):
in tkrzw 1.0.27 built thusly under Debian sid amd64:
Most of the crashes on those files are controlled asserts caused by attempts to allocate terabytes of memory or more; however, there are also wild pointer accesses, heap-based buffer overflows, etc. Only the
tkhfile type didn't fall to afl-fuzz (yet);tkmb tkmc tkmt tks tksh tkst tktdid, most of them for all five commands, often within the first few seconds of fuzzing, if not the first dozens of milliseconds. Some of them reached ~2% crash rate.FTR:
The initial corpus of valid files was built by
afl-fuzzinvocations:I then massaged the output folders for easier use on the maintainer side :)