syzkaller: panic: runtime error: invalid memory address or nil pointer dereference

When running latest master version of syzkaller we got message below after ~1-3 hours of fuzzing.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xb563ac]

goroutine 5060 [running]:
github.com/google/syzkaller/pkg/cover.(*Convert).convertPC(0xc000801340, 0x85bd3c8)
	/opt/syzkaller/pkg/cover/canonicalizer.go:160 +0x6c
github.com/google/syzkaller/pkg/cover.(*Convert).convertPCs(0xe6838bd00?, {0xc000b4e4b0, 0x39, 0x404b6c?}, {{0xc0021a0118, 0x2, 0x2}, {0xc0021a0170, 0x2, 0x2}})
	/opt/syzkaller/pkg/cover/canonicalizer.go:146 +0x45
github.com/google/syzkaller/pkg/cover.(*CanonicalizerInstance).Decanonicalize(...)
	/opt/syzkaller/pkg/cover/canonicalizer.go:117
main.(*RPCServer).Poll(0xc000a38420, 0xc000142910, 0xc000a37e00)
	/opt/syzkaller/syz-manager/rpc.go:380 +0xe9b
reflect.Value.call({0xc001bf7ec0?, 0xc000a3dc40?, 0x13?}, {0x1417350, 0x4}, {0xc00237def8, 0x3, 0x3?})
	/opt/go/src/reflect/value.go:584 +0x8c5
reflect.Value.Call({0xc001bf7ec0?, 0xc000a3dc40?, 0x203000?}, {0xc000b1f6f8?, 0x13ab6e0?, 0x18b4a50?})
	/opt/go/src/reflect/value.go:368 +0xbc
net/rpc.(*service).call(0xc00012b380, 0xc0004eb000?, 0x7f56679d33a0?, 0xc000a2fb20, 0xc000a34700, 0xc000b1f7d0?, {0x10c2ec0?, 0xc000142910?, 0x18b27d0?}, {0x10c2f00, ...}, ...)
	/opt/go/src/net/rpc/server.go:382 +0x226
created by net/rpc.(*Server).ServeCodec
	/opt/go/src/net/rpc/server.go:479 +0x3fe

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Comments: 24 (7 by maintainers)

Commits related to this issue

Most upvoted comments

Maybe syz-manager should not be doing the translation. Can we have the syz-executors handle the canonicalization instead?

This would be a straightforward solution, but I’m concerned that having the executors handle the canonicalization would slow down execution speed, as this adds an extra execution for each syscall

But we still need to consider the case when the canonical set of modules itself is not complete.

@a-nogikh Given dynamic module loads/unloads, should we assume that the canonical set of modules is never complete?