OpenBSD uses cvs and does not enforce the standard Git convention for
commit messages of putting a summary followed by a new line and body.
If such commit[1] contains a `Reported-by` header, it's currently not
detected. Instead, if the body is empty try to extract data from the
commit summary.
[1] bdbfbec5ce
This commit fixes a handle leak in syz_mmap. The bug was pointed out by
mdempsky during a code review.
The `syz_mmap` function creates a VMO and maps it to a VMAR in the address
specified by the `syz_mmap` parameters. Once a VMO is mapped to a vmar,
the handle to the vmo can be closed without problems.
The new code makes sure that `zx_handle_close(vmo_handle)` gets called before
the `syz_mmap` function returns.
syz_mmap is a pseudo-syscall that can be used by syzkaller in fuzzing
programs, however, it is also used to setup the environment for
syz-executor. syz-executor already checks the return value[0] when it is
used for setting up the environment, so it doesn't make sense for the
function to crash (most probably, in a fuzzing program it will be called
with arguments that would make it fail).
The previous behavior was causing a bunch of "Lost connection to test
machine" syzkaller crashes which were meaningless. An example of a
program in which syz_mmap would crash would be any program in which the
handle to the root vmar is closed before calling syz_mmap.
[0]:
a60cb4cd84/executor/executor_fuchsia.h (L15)
This change reuses the logic for sending the output back from
syz-executor to syz-fuzzer that forkserver oses use: reading it
periodically. This will be useful for debugging issues in Fuchsia that
does not support forkserver yet.
syz-symbolize did not use the common mgrconfig logic
to calculate kernel dirs. Thus KernelBuildSrc ended up empty,
+dirs were not extended to absolute paths.
Use the common mgrconfig logic to calculate kernel dirs.
Kbuild inserts build timestamp into every build.
This makes vmlinux change always even if no present.
Make the build more deterministic.
We plan to use it for detecting no-op changes during bisection.
Update #1271
* Modify mail_bisect_result.txt to allow for sending fix bisection
results.
* Modify BisectResult to have a Fix field; introduce selectBisect for
use within the template for choosing between BisectCause/BisectFix
fields.
* Modify bisectFromJob() to return BisectResult with Fix field set if
relevant.
* Modify the tests inside bisect_test.go to account for bisect fix
related reporting emails.
* Modify incomingMail() to ignore any emails from syzbot itself.
Reports from witness regarding returning to userspace with locks held is not
unique enough, causing all lock leaks to be grouped under the same bug.
Instead try to extract the name of syscall where the first held lock was
grabbed.
While here, shorten the title a bit.
Go support is not a priority for Fuchsia at the moment, so it's
preferable to use host fuzzing mode for Fuchsia like currently done
for Akaros.
This commit basically looks for all the places where there was special
logic for OS=="akaros" and extends the same logic for OS=="fuchsia".
MAX_STACK_TRACE_ENTRIES crash reports caused by a particular issues can come
from any part of the kernel, so bucketing them based on the stack trace is
pointless and only creates duplicate bug reports.
We have noticed that the build process was being invoked as root. This
change modifies the calls to use osutil.Sandbox before invoking cmds to
build fuchsia.
This is required for the process to use goma, as goma is running under
the syzkaller user.
