| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
It popped up in a new KASAN report after recent KASAN changes.
|
| | |
|
| |
|
|
|
| |
Reported-by: syzbot+aada2d85478c047a3cbf@syzkaller.appspotmail.com
Signed-off-by: Andrei Vagin <avagin@google.com>
|
| |
|
|
|
| |
ref_tracker is a generic debugging facility,
the actual bug is (almost always) in the caller.
|
| |
|
|
| |
That's some mutex internals.
|
| |
|
|
|
|
|
|
| |
Support extracting multiple frames from a single report
(one per parseStackTrace marker). Extract KMSAN origin
frame and use it as an additional ALT title for deduplication.
Fixes #2927
|
| |
|
|
|
|
| |
Keeping backwards compatibility will complicate future changes.
Since KMSAN is not upstream yet and is always rebased, we don't
really need to keep parsing old reports.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
These are not the root cause of bugs and should be skipped.
|
| | |
|
| |
|
|
|
|
|
| |
Not skipping this frame leads to "BUG: sleeping function called from
invalid context at" pointing to the wrong function.
Fix that and add a report parse test.
|
| |
|
|
|
|
|
|
|
| |
Memory access errors inside the crc-calculating functions typically
indicate an error in the calling function, rather than a bug in the CRC
implementation.
Skip them during stack frame parsing. Add a new report test that
validates the new behavior.
|
| |
|
|
|
|
|
|
|
| |
Currently KMSAN does not include the "Call Trace" line into its reports.
As syzkaller still expects it, most of those reports end up being
classified as corruped and do not get published by syzbot (see #2733).
Adjust the parsing rules to support these new reports.
Add a test to validate the new behavior.
|
| |
|
|
|
|
| |
This bug message includes filesystem type and block device name.
Both can lead to excessive duplicates.
Merge all such bugs together.
|
| |
|
|
|
|
|
| |
gcc and clang somehow print different frames around syscall entry.
sys_-prefixed names is what currently produced for gcc (more common)
and we have lots of existing reports with sys_ prefix.
So make the clang frames parsed the same way as gcc frames are currently parsed.
|
| |
|
|
| |
This routine was recently renamed.
|
| |
|
|
|
|
|
| |
Logs containing "*** stack smashing detected ***: terminated" are not of
particular interest, as this indicates syz-executor corruption.
Suppress bug reports in this case.
|
| |
|
|
|
|
|
| |
This error originates in glibc and is occasionally printed by
corrupted syz-executor instances.
Do not recognize it as a kernel crash.
|
| |
|
|
|
|
|
|
| |
In Linux 5.15 the mand mount option will be deprecated, and the warning
text will change accordingly:
https://lkml.kernel.org/r/20210820163919.435135-3-jlayton@kernel.org/
Update regex to also ignore this case.
|
| |
|
|
|
|
|
| |
Ignore this new warning, as it is intentionally added to warn users and
does not indicate a kernel bug:
https://lkml.kernel.org/r/CAHk-=wgD-SNxB=2iCurEoP=RjrciRgLtXZ7R_DejK+mXF2etfg@mail.gmail.com
|
| |
|
|
|
|
|
|
|
|
|
| |
Skip Code: lines that refer to user-space. Skip code listings where the
trapping instruction is an intentionally invalid one (this happens in
WARNINGs and most of BUG reports). Decompilation of such code fragments
provides no value to the user.
Add new tests and update the existing ones.
Closes #2709 and #2710.
|
| |
|
|
|
|
|
|
| |
Let decompiler also parse the exact command name. Perform right trim on
the full output line, as it may contain tabs and spaces at the end.
Introduce an "-update" flag to facilitate mass updating of opcode
decompilation tests after changes to this functionality.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Replace not just long sequences of digits in report titles, but every
sequence of '0'-'9' that is not surrounded by word characters.
As such matches will overlap and Go does not (currently?) support regexp
lookarounds, do the replacement multiple times until there is nothing
more to do. This should not slow down syzkaller, since this code is
only invoked during crash processing.
Restrict LINE replacement only to fragments that have a preceeding file
name. This prevents replacements like [1:2] -> [NUM:LINE].
|
| |
|
|
|
|
|
|
|
|
|
| |
Improve Linux reports quality by decompiling "Code: " descriptions.
As that line of opcodes is not guaranteed to begin at the boundary of an
instruction, try to find the right boundary.
Handle the cases of multiple "Code: ..." lines by only decompiling the
first one. In most cases the last such line shows user-space bytes,
which is usually not of great importance.
|
| |
|
|
|
| |
We ignored some el1_* arm64 frames, but not a new el1h_64_sync
frame appeared in HWASAN reports. Ignore it as well.
|
| |
|
|
|
|
|
| |
Now that we increased CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT to 16
we started getting full parsable "stack guard page was hit" crashes.
Extract the anchor frame as we do for stalls.
This makes reports deterministic rather than point to a random top frame.
|
| |
|
|
|
|
|
|
| |
The format of the panic message means that we get lots of duplicate
reports. Normalize KASAN report titles. In particular, strip the code
name since it encodes the size of the redzone, which may vary depending
on the test case, especially if the report is triggered by a false
positive.
|
| |
|
|
| |
Some kernel code seems to have been changed again...
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are getting some duplicate reports where the stall actually happens
in some syscall, but the syscall triggers a page fault repeatedly.
As the result we can attribute some of the stalls to the next frame
after handle_mm_fault.
So don't consider handle_mm_fault as an anchor frame.
We need to be careful to not skip entry into page fault
from user space, because that's a completly different case.
In that case the stall is indeed in the page fault handler.
It's also unclear if this is the right thing to do.
If the stall actually happens in the fault handler
and the root cause in the fault handler, then after this change
we will produce duplicate stalls for every place in the kernel
that can trigger a page fault (we will be skipping the handler
itself and attribute it to the innocent caller).
But so far we don't have such examples.
|
| |
|
|
|
| |
Suggested-by: Vegard Nossum
Link: https://groups.google.com/g/syzkaller/c/aHHCG_ZHOZA/m/M6aiIuzkAQAJ
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The witness output was recently changed in order to aid tracking down
scenarios in which lock ordering data is missing. This is probably a bug
and turning them into unique reports should hopefully help syzkaller
being able to find a reproducer.
The existing inode suppression must be tweaked a bit order to not flag
the relevant reports as suppressed.
|
| |
|
|
|
| |
Ignore cases that match "INFO:" that were not important.
These occured on Pixel3XL running Android 11.
|
| |
|
|
|
| |
Extracted from:
https://groups.google.com/g/syzkaller/c/cXw5z215P5E/m/jBvwJ3IsAQAJ
|
| | |
|
| |
|
|
|
|
|
|
| |
kcsan_setup_watchpoint() reads the value before and after the delay to
check for value changes. If the memory location is inaccessible, do not
report the bug in kcsan_setup_watchpoint() but instead in the caller.
This also allows properly deduplicating related reports from non-KCSAN
configs.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently all executor fail errors go into "lost connection" bucket.
This is not very useful. First, there are different executor failures.
Second, it's not possible to understand what failures happen how frequently.
Third, there are not authentic lost connection.
Create separate SYZFAIL: bugs for them.
Update #573
Update #502
Update #318
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Both these passive hangs sometimes happen due to the same underlying issue.
Merge them together.
Update #1575
|
| |
|
|
|
|
|
| |
Both these active stalls sometimes happen due to the same underlying issue.
Merge them together.
Update #1575
|
| |
|
|
| |
Update #1575
|