-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Placeholder: Fuzzing with AFL #1
Comments
On Wed, May 27, 2020 at 03:11:31PM -0700, Derrick Lyndon Pallas wrote:
I set up AFL to run smatch against some of the validation files & it has found a few crashes so far. This is a placeholder to note that. What is the best way (vis-à-vis, your workflow) to report these crashes?
Ah. Thanks.
You could email them to smatch@vger.kernel.org or to me directly.
regards,
dan carpenter
|
Thanks. All but two that I've seen so far are null dereferences in the parse tree when the input is invalid. |
The other two are adding to an invalid |
It looks like most of the cases are where the right half of an expression is bad but the expression is still passed back up. I have the sources of the ones I could find fixed but there are still other cases where a bad parse input causes the tree to be invalid and a client function does not check for this condition. |
On Thu, May 28, 2020 at 07:18:48PM -0700, Derrick Lyndon Pallas wrote:
It looks like most of the cases are where the right half of an
expression is bad but the expression is still passed back up. I have
the sources of the ones I could find fixed but there are still other
cases where a bad parse input causes the tree to be invalid and a
client function does not check for this condition.
If you have sample code which causes the crash and do a
`valgrind ./smatch test.c` that normally gives a good stack trace and
it's easy enough to add a NULL check.
The unfortunate thing is that often the checks expect valid code so they
all have the same bugs. :/
regards,
dan carpenter
|
Unrelated fix: In match_memdup() then I added some add_dereference(left/right) calls. Problem: This codes a tangled mess and zeroing memory does not work. This code is supposed to handle three things. #1 Copying a known struct to a different struct of the same type. #2 Copying unknown data to a struct. #3 Copying a zeroed buffer to a struct. I think #1 basically works. It's hard to get #2 wrong so I think that works but probably in the wrong way. But #3 was not working. In the original code, it treated "struct = struct" as different from memcpying. Which is sort of not a bad idea, but not how it's implemented. So get rid of that. Just say COPY_NORMAL. Use COPY_UNKNOWN for #2 of an unknown buffer and COPY_ZERO for a zeroed buffer. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
I set up AFL to run smatch against some of the validation files & it has found a few crashes so far. This is a placeholder to note that. What is the best way (vis-à-vis, your workflow) to report these crashes?
The text was updated successfully, but these errors were encountered: