| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
| |
We have quite a few comedi bugs now, let's not keep them all in
"kernel".
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
It will help keep more generic reports in "net".
|
| |
|
|
| |
Adjust subsystem generation code to the latest changes.
|
| |
|
|
| |
See https://lore.kernel.org/all/20230908082846.GB9560@lst.de/
|
| |
|
|
|
| |
Regenerate the list using v6.5-rc5.
Also, rename fat -> exfat.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
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.
|
| |
|
|
| |
Add isofs and fat. Match them with their pseudo syscalls.
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
| |
There were cases when subsystems did not get reasonable enough names.
|
| |
|
|
|
|
| |
Despite the automatic logic we already have, there are still a few
emails that slip the check. For now let's keep them in a separate array,
maybe later we'll figure out a pattern.
|
| |
|
|
| |
This information will let us extract subsystems from reproducers.
|
| |
|