On Wed, Jun 15, 2022 at 12:55 PM Liam Howlett <liam.howlett@xxxxxxxxxx> wrote: > > * Yu Zhao <yuzhao@xxxxxxxxxx> [220615 14:08]: > > On Wed, Jun 15, 2022 at 8:25 AM Liam Howlett <liam.howlett@xxxxxxxxxx> wrote: > > > > > > * Yu Zhao <yuzhao@xxxxxxxxxx> [220611 17:50]: > > > > On Sat, Jun 11, 2022 at 2:11 PM Yu Zhao <yuzhao@xxxxxxxxxx> wrote: > > > > > > > > > > On Mon, Jun 6, 2022 at 10:40 AM Qian Cai <quic_qiancai@xxxxxxxxxxx> wrote: > > > > > > > > > > > > On Mon, Jun 06, 2022 at 04:19:52PM +0000, Liam Howlett wrote: > > > > > > > Does your syscall fuzzer create a reproducer? This looks like arm64 > > > > > > > and says 5.18.0-next-20220603 again. Was this bisected to the patch > > > > > > > above? > > > > > > > > > > > > This was triggered by running the fuzzer over the weekend. > > > > > > > > > > > > $ trinity -C 160 > > > > > > > > > > > > No bisection was done. It was only brought up here because the trace > > > > > > pointed to do_mas_munmap() which was introduced here. > > > > > > > > > > Liam, > > > > > > > > > > I'm getting a similar crash on arm64 -- the allocator is madvise(), > > > > > not mprotect(). Please take a look. > > > > > > > > Another crash on x86_64, which seems different: > > > > > > Thanks for this. I was able to reproduce the other crashes that you and > > > Qian reported. I've sent out a patch set to Andrew to apply to the > > > branch which includes the fix for them and an unrelated issue discovered > > > when I wrote the testcases to cover what was going on here. > > > > Thanks. I'm restarting the test and will report the results in a few hours. > > > > > > BUG: KASAN: slab-out-of-bounds in mab_mas_cp+0x2d9/0x6c0 > > > > Write of size 136 at addr ffff88c5a2319c80 by task stress-ng/18461 > > ^^^^^^^^^ > > > > > As for this crash, I was unable to reproduce and the code I just sent > > > out changes this code a lot. Was this running with "trinity -c madvise" > > > or another use case/fuzzer? > > > > This is also stress-ng (same as the one on arm64). The test stopped > > before it could try syzkaller (fuzzer). > > Thanks. What are the arguments to stress-ng you use? I've run > "stress-ng --class vm -a 20 -t 600s --temp-path /tmp" until it OOMs on > my vm, but it only has 8GB of ram. Yes, I used the same parameters with 512GB of RAM, and the kernel with KASAN and other debug options.
