| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
The action takes a list of findings and runs their reproducers on the
base and the patched kernel.
|
| |
|
|
|
|
|
|
| |
Test steps constitute sub-steps of a particular test step.
These will be used for pesisting the information about the reproducers
that are rerun on newer patch series and about individual kernel tests
(if/when we add integrate it will kunit/kselftests/other testing
utilities).
|
| |
|
|
|
| |
The API call returns an aggregated list of findings in all previous
versions of the specified patch series.
|
| |
|
|
|
| |
The API method can be used to query more details about a finding by its
UUID.
|
| |
|
|
|
| |
Combine kernel build requests with a list of actions to perform on those
kernel builds. This will simplify adding more actions later.
|
| |
|
|
| |
This change will reduce confusion when we add nested tests.
|
| |
|
|
| |
This will simplify further changes.
|
| | |
|
| |
|
|
|
|
| |
Poll the tree and consider it during patch series triage. Note that the
media lists are not monitored as of now, so the tree will only be used
when we receive media patches through other mailing lists.
|
| |
|
|
|
|
| |
Add some initial #syz invalid support to syz-cluster. For now, mark all
findings as invalid and don't display that such series have findings on
the web dashboard.
|
| |
|
|
|
|
|
|
| |
Add the drm tree to the list of trees considered during patch series
triage.
Currently we sometimes hit false positives becase of not considering
this tree, see e.g. https://ci.syzbot.org/series/1ecba15f-79c3-40ff-99c6-8f3540bddf65
|
| |
|
|
|
|
| |
A number of mm patches do not apply neither on top of torvalds, nor on
top of linux-next. The mm/mm-new branch seems to be a more reliable
base.
|
| |
|
|
|
|
|
|
| |
Instead of a predefined set of manually written syz-manager configs,
construct it dynamically from different bits.
During triage, select not just one, but all matching fuzzer
configurations and then merge them together.
|
| |
|
|
|
|
|
|
| |
During triage, process each fuzzing campaign separately as they may have
different base kernel revisions (e.g. if the newest revisions of the
kernel no longer build/boot under the specific kernel configuration).
Refactor the representation of the fuzzing targets in api.go.
|
| |
|
|
|
| |
Specify a track name for each fuzzing campaign.
It will help distinguish them once there are multiple ones.
|
| |
|
|
|
| |
Instead of just checking whether the bug was observed on the base crash,
accept a regexp of accepted bug titles as well.
|
| |
|
|
|
| |
Adjut the workflow template and the API to run multiple fuzzing
campaigns as a part of single patch series processing.
|
| |
|
|
|
|
|
|
| |
There are a number of patch series that don't apply to torvalds, but do
apply to linux-next.
Since we don't fetch all maintainer trees, use linux-next as the last
resort.
|
| |
|
|
|
| |
Some series don't apply to torvalds, see e.g.
https://ci.syzbot.org/series/f429573e-7862-4f1e-97dd-3215a235b1d3
|
| | |
|
| |
|
|
|
| |
When fuzzing fs-related series, enable fs syscalls and use the fs
corpus.
|
| |
|
|
| |
Track base crashes for (commit hash, config, arch) tuples.
|
| |
|
|
|
|
|
|
| |
If all symbol hashes between the base and the pathed kernel match,
there's no reason to spend time fuzzing the series.
Add a 'skipped' status to the enum of possible session test results and
set it from the fuzz-step.
|
| | |
|
| |
|
|
|
|
|
|
| |
There are cases when we do not need the "if the patched code is not
reached within 30 minutes, abort fuzzing" check.
This is e.g. the case of mm/ code that is not fully instrumented by
KCOV.
|
| |
|
|
|
|
|
|
| |
Keep the fuzz-step parameters in a separate structure to minimize the
field duplication.
It will also facilitate the reuse of the same syzkaller config in
several fuzzing configurations.
|
| | |
|
| |
|
|
| |
Use a custom set of enabled syscalls.
|
| |
|
|
|
| |
Add a config to fuzz kvm patches.
Listen on the kvm mailing list.
|
| |
|
|
|
|
|
|
| |
Not always are fuzzing targets well represented by their own kernel
trees, so let's select a kernel tree and a fuzzing config separately.
Drop explicit priorities and instead just sort the lists of trees and
configs.
|
| |
|
|
|
|
|
|
| |
We used to only upload them on triage failure, but let's improve the
inspectability even for successfully finished triage jobs.
Slightly refactor the controller API around the triage result
submission.
|
| |
|
|
|
|
| |
Fuzz bpf patches differently from net patches.
Monitor netfilter and bpf mailing lists
|
| | |
|
| |
|
|
|
|
|
| |
Current results show that way too many series do not apply to the
non-next versions of their corresponding trees. So let's make -next the
default choice unless it the opposite was specified in the series
subject.
|
| |
|
|
|
| |
Add several more network-related trees, including those that will only
be selected if mentioned directly.
|
| |
|
|
|
| |
Sometimes the patch series directly hint at the kernel tree they should
be applied to. Extract and remember this information.
|
| |
|
|
|
|
|
|
|
| |
Currently, the list was both within the Series object and within the
SessionReport object that also encloses Series. And, since only was was
actually filled, we were unable to actually Cc the people from the
series.
Keep only the Cc list in the Series object and adjust the tests.
|
| |
|
|
|
|
|
|
| |
Share not just the tree name (mainline, net, etc), but also the full URL
to check out the repository.
For that, add one more field to the Build entity and adjust email
reporting templates.
|
| | |
|
| |
|
|
|
| |
Take web dashboard URL from the config and use it to generate links for
logs, reproducers, etc.
|
| |
|
|
|
|
|
| |
Fill in build details per each finding and display that information in
the report email.
Extend the test that verifies how api.SessionReport is filled.
|
| |
|
|
|
|
| |
Replace an UpdateReport() call with a RecordReply(). This will
eventually allow us to support the email sender implementations for
which we do not immediately know the MessageID of the reported message.
|
| | |
|
| |
|
|
|
| |
Add API to record replies under the reports that allows to determine the
original report only by having the MessageID.
|
| |
|
|
|
|
|
|
| |
Since email-reporter is anyway tied to a specific reporting channel,
let's keep reporter names less generic.
Using "lkml" instead of just "email" will also let us generate proper
links to the email discussions based only on Reporter+MessageID.
|
| |
|
|
|
| |
Introduce a Reporter column to the SessionReport.
For finished reports, store both a MessageID instead of Link.
|
| |
|
|
| |
For now, only share it for the skipped series.
|
| |
|
|
|
|
|
|
|
|
|
| |
The archive would be a useful source of debugging information.
Provide an HTTP endpoint that accepts a multipart form request with
the archived data.
Provide an *api.Client method to encapsulate the encoding of the data.
Add a test.
|
| | |
|
| |
|
|
|
|
| |
Refactor Tree structure to host both the kernel config and the fuzzer
config.
Add some basic net fuzzing configs.
|