| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
| |
When configuring focus areas before directed fuzzing, construct regular
expressions that match the exact function names. Otherwise, we end up
adding more functions than intended.
|
| |
|
|
|
|
|
|
|
|
| |
We return Ctime from CreationTime. But "C" does not stand for "creation",
it stands for "status change" (inode update). It may or may not be the
creation time.
Use Btime (birth time) for creation time.
Fixes #6547
|
| |
|
|
| |
Return not just the modified files, but also their blob hashes.
|
| |
|
|
|
| |
Sorting using numSort for column with empty non-number rows does not work.
Always print repro attemps, but make 0 inactive (gray).
|
| |
|
|
| |
Any is the preferred over interface{} now in Go.
|
| |
|
|
|
|
|
|
|
| |
In the presence of numerous program seeds that mount fs images, our html
coverage reports end up being as big as 1GB, which makes it problematic
to render/manipulate them in the web browser.
Adjust coverage report generation: once the total size of program seeds
exceeds 100MB, switch to the compact seed serialization mode.
|
| |
|
|
|
|
|
| |
There are still situations where we don't properly terminate fuzzing on
context cancelation.
Add more logging to debug it.
|
| |
|
|
|
| |
We don't need it to hold it for the call to the externally supplied
callback.
|
| |
|
|
|
| |
Instead of just checking whether the bug was observed on the base crash,
accept a regexp of accepted bug titles as well.
|
| | |
|
| | |
|
| |
|
|
| |
Send only the first report to dashboard.
|
| | |
|
| | |
|
| |
|
|
| |
Add a new column next to it to list the number of repro attempts separately.
|
| |
|
|
|
|
|
| |
When we run a reproducer on a base kernel and it crashes, we must record
the crash title observed on the base kernel.
Rename the field to reduce the chance of confusion in the future.
|
| |
|
|
|
|
| |
Report base kernel crashes observed during fuzzing.
Consult the common API for each patched kernel crash to see if it was
already observed on the base kernel.
|
| |
|
|
|
| |
1. func Run optionally accepts the opts.
2. Some refactoring, more comments.
|
| |
|
|
| |
This reduces the redundancy a bit.
|
| |
|
|
|
|
| |
On the syz-manager's html dashboard, dispay the number of repro attempts
per each bug. It will help distinguish the bugs where reproduction
was attempted and failed from those that have never been reproduced yet.
|
| |
|
|
| |
The VM pool expects us to listen on the boot error channel.
|
| |
|
|
|
| |
It's been checking the inverse of what was needed.
Rename the helper function to reduce confusion in the future.
|
| |
|
|
|
|
| |
Instead of calling grep (the implementations of which may differ in
different environments), traverse the directory and grep files with a
special pkg/osutil helper functionality.
|
| |
|
|
| |
If the manager name is set, display it in the header.
|
| |
|
|
|
|
|
| |
The rules were too generic - there are plenty of functions that have
"stall" as substring, yet they do not relate to rcu stall bugs.
Improve the rules list and add a unit test.
|
| |
|
|
|
|
|
|
| |
After ensuring that a bug only affects the patched kernel, do one more
round of reproduction and (if successful) re-report the result.
This will ensure that, provided enough time, diff fuzzing results will
also have minimalistic C reproducers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We used to generate a choice table and do its normalization for all
present syscalls, also it was not considered during the /prio page
generation.
Enabled/disabled syscalls were accounted for in the choice table
construction, but there's a chance that the resulting table was still
somewhat skewed.
The situation must have become worse after several thousands of auto
syscalls were added.
|
| |
|
|
|
| |
The previous message was misleading - executor's coverage filter can
well be 0, it's the number of PCs per focus area that's of interest.
|
| |
|
|
| |
Right at the Loop() start, these are not filled out yet.
|
| |
|
|
|
|
|
|
|
| |
Hash the code section of the individual symbols from vmlinux.o and use
it to determine the functions that changed their bodies between the base
and the patched build.
If the number of affected symbols is reasonable (<5%), fuzz it with the
highest priority.
|
| |
|
|
| |
For that, make a part of the tar_test.go reusable.
|
| |
|
|
| |
These are already symbolized in pkg/repro.
|
| |
|
|
|
| |
If we matched 0 PCs for the areas of focused fuzzing, don't abort the
process after 30 minutes.
|
| |
|
|
|
| |
Use the context provided via errgroup.Group so that a single error can
successfully shut down the whole diff fuzzing process.
|
| |
|
|
|
| |
Don't waste time doing focused fuzzing if no modified code has
been reached in 30 minutes after corpus triage.
|
| |
|
|
|
|
| |
In syz-manager, we symbolize reports right before saving them. Follow a
similar approach for diff fuzzing as well and symbolize only the reports
which were confirmed to only affect the patched kernel.
|
| |
|
|
|
|
| |
During diff fuzzing, ignore too unreliable reproducers completely.
For moderately reliable ones, do a larger number of runs.
|
| |
|
|
| |
It allows to use context as a single termination signal source.
|
| |
|
|
|
|
|
|
|
| |
When running the reproducer from the patched kernel on the base kernel,
stay on the safe side when encountering errors and context
cancellations.
Always demand 3 successful executions before declaring a bug
patched-only.
|
| |
|
|
|
|
|
| |
Writes to channels are dangerous in the presence of context cancellation
- no one may be listening on the receiving side.
Wrap the writes in a select that also awaits ctx.Done().
|
| |
|
|
|
|
|
| |
It's still unclear what exactly is causing the fuzzer to not halt at
context cancellation.
Log the termination of the internal syz-diff loops.
|
| |
|
|
|
|
|
|
|
|
| |
Make the pool.Run() function take a context.Context to be able to abort
the callback passed to it or abort its scheduling if it's not yet
running.
Otherwise, if the callback is not yet started and the pool's Loop is
aborted, we risk waiting for pool.Run() forever. It prevents the normal
shutdown of repro.Run() and, consequently, the DiffFuzzer functionality.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As pingQueue holds maximum 1 element, it's not a very good indicator of
whether there are more elements in the reproduction queue. If the first
few crashes happen to be no longer needed (which is quite likely when
reproduction loop is started long after we have begun to collect the
crashes), the loop becomes reactive - new reproductions will be started
only once new bugs are submitted to the queue.
Fix it by polling the queue until it returns nil. Add a test that
exposes the previously existing bug.
|
| |
|
|
|
|
|
|
|
| |
We already mention the scheduled and started reproductions, but if the
reproduction was not started intentionally, that makes the logs look
very confusing.
Print a log message if NeedRepro() returned false when we were to
actually start the reproduction.
|
| |
|
|
|
|
|
|
| |
When the context is cancelled, no one may be polling the pingQueue, yet
we write to it synchronously.
Wrap it in a select{} statement and add a test to ensure that the loop
reacts properly to the context cancellation.
|
| |
|
|
|
|
| |
Make the fuzzing step of syz-cluster create the manager.DiffStore object
explicitly and dump its state to the logs after finishing the fuzzing
session.
|
| |
|
|
|
| |
If the context is cancelled, we need to make sure that the reproduction
process is aborted as well.
|
| |
|
|
|
|
|
| |
It may be introducing false positives into the process of determining
whether the bug affects the base kernel.
Let's stay on the safe side and not do it for now.
|
| |
|
|
|
| |
While doing a blocking write to the channel, take the possibility of the
context closure into account.
|