| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Don't print object size (can change from kernel to kernel
and from config to config).
Fix function extraction regexp (must be non-eager).
Account for MSECS_MIN_AGE.
Ignore some known false positives.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
open is not present on arm64, only openat.
accept is not present on 386, only accept4.
Duplicate all open/accept specializations with
corresponding openat/accept4 specializations
to enable testing on 386/arm64.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Few managers recently crashed with:
panic: syscall mknod$loop: per proc arg 'proc' has bad value '4294967295'
panic: sync: unlock of unlocked mutex
goroutine 35438 [running]:
sync.(*Mutex).Unlock(0xc42166e0c8)
sync/mutex.go:184 +0xc1
panic(0xb98980, 0xc448971aa0)
runtime/panic.go:491 +0x283
main.(*Manager).Connect(0xc42166e000, 0xc42056d060, 0xc42038f000, 0x0, 0x0)
syz-manager/manager.go:868 +0x11cc
And a similar issue was reported on mailing list.
It's unclear where these bogus programs come from.
It seems that hub was somehow involved here.
4294967295 is (uint32)-1 which is trucated special
value for proc types.
The test did not uncover any bugs, bug since I wrote it
and it looks like a useful test, let's commit it anyway.
|
| | |
|
| |
|
|
|
| |
Note: ion supercedes the old android interface,
which is moved to sys/android.
|
| | |
|
| | |
|
| |
|
|
|
| |
We must not skip reporting if we already reported a bug to it.
This leaves orphaned bugs.
|
| |
|
|
| |
Greatly improves log readability at a cost of minimal size increase.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds builtin:
type bool8 int8[0:1]
type bool16 int16[0:1]
type bool32 int32[0:1]
type bool64 int64[0:1]
type boolptr intptr[0:1]
We used to use just int's for bools.
But bool types provide several advantages:
- make true/false probability equal
- improve description expressiveness
- reduce search space (we will take advantage of this later)
|
| | |
|
| | |
|
| |
|
|
|
|
| |
type sock_port proc[20000, 4, int16be]
That was repeated a few times.
|
| |
|
|
|
|
|
| |
We don't need compiler support for such things anymore,
now we simply can do:
type signalno int32[0:65]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Complex types that are often repeated can be given short type aliases using the
following syntax:
```
type identifier underlying_type
```
For example:
```
type signalno int32[0:65]
type net_port proc[20000, 4, int16be]
```
Then, type alias can be used instead of the underlying type in any contexts.
Underlying type needs to be described as if it's a struct field, that is,
with the base type if it's required. However, type alias can be used as syscall
arguments as well. Underlying types are currently restricted to integer types,
`ptr`, `ptr64`, `const`, `flags` and `proc` types.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Test we actually can get an unnatural len value.
|
| |
|
|
| |
This is need for few crypto/xfrm descriptions.
|
| |
|
|
| |
Helps to understand what program caused it.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
On another machine both clang and gcc produce:
test.c:163:32: error: invalid suffix "+procid" on integer constant
*(uint32_t*)0x20001004 = 0x25dfdbfe+procid*4;
Not sure why this wasn't caught on buildbot.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #183
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Mostly extensions of API in 4.15.
|
| | |
|
| |
|
|
| |
Somebody discusses something, we don't care anymore.
|
| |
|
|
|
|
| |
When somebody sends us our own email back without quoting,
we used to extract "#syz fix: exact-commit-title" from it.
Ignore such emails.
|
| |
|
|
|
|
|
| |
Reporting statuses are not flexible as they can't encode
all possible conditions. ReportingPassThrough is a good example.
Replace Status with Filter which accepts bug and can contain
arbitrary logic.
|
| |
|
|
| |
Just unnecessary clutter.
|
| |
|
|
| |
...was wrong all that time
|
| |
|
|
|
|
|
| |
Remove dup newlines around includes.
Makes int values shorter if not hurting readability.
Increase line len to 80.
Remove {} when not needed during copyout.
|
| | |
|
| |
|
|
| |
Otherwise they get merged with other corrupted reports.
|
| |
|
|
|
|
|
| |
We see these warnings when people CC syzbot on unrelated threads.
If there is no command in the email, don't produce warning at all.
On the other hand if there is a command, warn and send sender
reply that syzbot can't find the corresponding bug.
|