| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Don't specify the subsystem revision in the dashboard config and instead
let it be nested in the registered subsystems. This reduces the amount
of the manual work needed to switch syzbot to a newer subsystem list.
|
| |
|
|
|
| |
We have quite a few comedi bugs now, let's not keep them all in
"kernel".
|
| |
|
|
| |
Regenerate the list using v6.16-rc7.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
There was a mistake in the Linux subsystem generation rules that led to
the exclusion of exfat-related syz_mount_image calls from the resulting
subsystem descriptions.
Verify the rules before applying them. Fix other problems found by the
check.
|
| |
|
|
|
|
|
|
|
| |
Split off kvm-x86 from kvm for better coverage accounting.
Both subsystems will still share the CC lists, so bugs in x86 code
won't be emailed twice.
While at this, also fix the tool name in the generated comment and
regenerate pkg/subsystem/lists/linux.go on v6.14-rc7.
|
| |
|
|
|
| |
It doesn't have its own mailing list, so needs to be defined manually.
See #5838.
|
| |
|
|
| |
Based on v6.14-rc7.
|
| | |
|
| |
|
|
|
|
| |
It used to be the case that, if a subsystem matches several rule
conditions, it could be returned several times. This has led to
incorrect parent inference results.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
syz_kvm_add_vcpu
The old syz_kvm_setup_cpu() API mixed together VM and VCPU setup, making it
harder to create and fuzz two VCPUs in the same VM.
Introduce two new pseudo-syscalls, syz_kvm_setup_syzos_vm() and syz_kvm_add_vcpu(),
that will simplify this task.
syz_kvm_setup_syzos_vm() takes a VM file descriptor, performs VM setup
(allocates guest memory and installs SYZOS code into it) and returns a
new kvm_syz_vm resource, which is in fact a pointer to `struct kvm_syz_vm`
encapsulating VM-specific data in the C code.
syz_kvm_add_vcpu() takes the VM ID denoted by kvm_syz_vm and creates a
new VCPU within that VM with a proper CPU number. It then stores the
fuzzer-supplied SYZOS API sequence into the corresponding part (indexed by
CPU number) of the VM memory slot, and sets up the CPU registers to interpret
that sequence.
The new pseudo-syscall let the fuzzer create independent CPUs that run different
code sequences without interfering with each other.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Use v6.9-rc7.
|
| |
|
|
|
|
| |
Our fs is more generic than it was defined in MAINTAINERS. Let's not
spam its mailing lists with bugs from individual filesystem
implementations.
|
| |
|
|
| |
This must be a strong signal to assign a bcachefs subsystem.
|
| | |
|
| |
|
|
|
| |
There are cases of very long names that make it too hard for the golang
library to properly parse the address.
|
| |
|
|
| |
We used to ignore the skipped lines.
|
| | |
|
| |
|
|
| |
It will help keep more generic reports in "net".
|
| |
|
|
| |
Adjust subsystem generation code to the latest changes.
|
| |
|
|
| |
The new mailing list can be parsed by the generic algorithm.
|
| |
|
|
| |
Use the latest torvalds master.
|
| |
|
|
| |
See https://lore.kernel.org/all/20230908082846.GB9560@lst.de/
|
| |
|
|
|
| |
If a record was specified in a custom subsystem list, do not consider it
while grouping records by mailing list.
|
| |
|
|
|
| |
Regenerate the list using v6.5-rc5.
Also, rename fat -> exfat.
|
| |
|
|
|
|
|
|
|
| |
The current syz-query-subsystems raise below error:
failed to query subsystems: failed to set names: failed to extract a name from kernel-tls-handshake@lists.linux.dev
This patch adds this email to exception list to fix that.
Signed-off-by: Lin Ma <linma@zju.edu.cn>
|
| | |
|
| |
|
|
|
|
| |
For some subsystems (e.g. `kernel`) such reports just don't make much
sense, since there are too many incorrectly classified bugs in there.
Make it possible to exclude such subsystems from periodic reminders.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's just accept that we cannot fully trust guilty paths and try to
increase the weight of subsystems extracted from reproducers.
Instead of taking all subsystems that have received the highest number
of votes, take all which have received >= 33%. This will reduce noise
and in almost all cases limit the number of assigned subsystems to 2.
If there are >= 3 reproducers that point to exactly the same set of
subsystems, give them a preference. But still take one subsystem from
guilty paths if there's one that's mentioned >= 66% times.
The numbers themselves are somewhat arbitrary, but hopefully this will
improve the quality of subsystem inference.
Add some more tests.
|
| |
|
|
|
|
|
|
|
|
|
| |
We currently prioritize a subsystem if it's present in all reproducers
and that is supported by at least one guilty path among the considered
crashes.
Due to a small bug in the code we only considered it to be supported if
the guilty path belonged to one of parent subsystems of the one
mentioned in the reproducer. It's fair to also consider full overlap
between them.
|
| |
|
|
|
|
|
| |
There was a small bug and, as a result, subsystems from reproducers
always superceded all other ones. That was not the desired side-effect.
Fix the logic and add a test to linux_test.go.
|
| |
|
|
| |
Also make the call point to the "input" subsystem.
|
| |
|
|
|
| |
Let's consider them a strong indicator that usb subsystem is affected by
a bug.
|
| |
|
|
|
| |
Adjust the rules so that syz_mount_image$nilfs2 begins to point to
nilfs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Earlier we only took maintainers if there was just one MAINTAINERS
record, but that was a very severe limitation.
Let's try a more elaborate approach. It's also not perfect, but allows
us to extract many more maintainers, while keeping false positives at
zero.
Group raw MAINTAINER records by their T: entries. If there's just one
set of T: values per group mailing list, take the intersection of M:
entries from there.
|
| |
|
|
| |
Rename `cluster` to `gfs2`
|
| | |
|
| |
|
|
|
|
|
|
|
| |
There are some minor subsystems (e.g. PAGE CACHE in Linux) that are
parts of several big subsystems. At the same time, a reproducer can
clearly disambiguate such case.
If subsystems from reproducers and subsystems from guilty files
intersect, only proceed with the results of the intersection.
|
| |
|
|
|
|
|
|
|
| |
We're not yet perfect at eliminating unneeded calls from reproducers, so
let's make the subsystem extraction rules stricter: only take a
subsystem from the reproducer if it's present in all reproducers.
Consider more crashes (7 instead of 5) to give more opportunities to
drop an unneeded call.
|
| | |
|
| |
|
|
|
|
| |
Two more flags:
- filter: allows to choose only a subset of the possible subsystems.
- emails: allows to force empty Lists and Maintainers.
|
| |
|
|
| |
Add isofs and fat. Match them with their pseudo syscalls.
|
| |
|
|
| |
9p is a much more common name.
|
| |
|
|
| |
Use the "v6.2" release.
|
| |
|
|
| |
We've put too much under the "fs" tag.
|
| |
|
|
|
|
|
| |
There are cases when a subsystem doesn't have a mailing list and yet
we'd prefer not to merge it with others. Let's add the ability to add
custom rules that join several specified MAINTAINERS records into one
Subsystem.
|
| | |
|