syz-manager: httpCoverCover panics with nil pointer dereference #2878
Comments
|
The panic happened when you tried to open the |
|
@a-nogikh I was not sure yet what was causing this panic or how to reproduce it as the web interface is on a public server and anyone can access it. But after your message I just now tried it and indeed I get the panic immediately if I try to access /cover. |
|
Hmm.. Looked at the code more closely. This is very strange and should not have been happening. I also was not able to reproduce it myself. Did you try to run a syzkaller instance with a clean |
|
@a-nogikh found the problem. This problem started since last few weeks and I was trying to remember what I did around that time. And I started using gcc-11 around that time. |
|
Good that you have found the triggering factor! But the very fact that this crash is possible is worrying. Syzkaller is not expected to exhibit such behaviour whatever kernel it runs on VMs. I have compiled the latest Linux kernel with If you don't mind, let's try to dig the problem a bit deeper. Could you please apply the patch below to syzkaller and make it crash? It would be then very helpful to see your syz-manager configuration and the full log. diff --git a/syz-manager/cover.go b/syz-manager/cover.go
index 8ddee085f..af97b8d6d 100644
--- a/syz-manager/cover.go
+++ b/syz-manager/cover.go
@@ -22,6 +22,7 @@ var getReportGenerator = func() func(cfg *mgrconfig.Config,
log.Logf(0, "initializing coverage information...")
rg, err = cover.MakeReportGenerator(cfg.SysTarget, cfg.Type, cfg.KernelObj, cfg.KernelSrc,
cfg.KernelBuildSrc, cfg.KernelSubsystem, cfg.ModuleObj, modules)
+ log.Logf(0, "initialized ReportGenerator: %p %v", rg, err)
})
return rg, err
}
@@ -29,8 +30,11 @@ var getReportGenerator = func() func(cfg *mgrconfig.Config,
func coverToPCs(rg *cover.ReportGenerator, cov []uint32) []uint64 {
pcs := make([]uint64, 0, len(cov))
- for _, pc := range cov {
+ for i, pc := range cov {
pcs = append(pcs, rg.RestorePC(pc))
+ if i == 0 {
+ log.Logf(0, "RestorePC successfully invoked")
+ }
}
return pcs
}
diff --git a/syz-manager/html.go b/syz-manager/html.go
index dc3e54519..32ec57946 100644
--- a/syz-manager/html.go
+++ b/syz-manager/html.go
@@ -284,6 +284,7 @@ func (mgr *Manager) httpCoverCover(w http.ResponseWriter, r *http.Request, funcF
}
rg, err := getReportGenerator(mgr.cfg, mgr.modules)
+ log.Logf(0, "getReportGenerator returned %p %v", rg, err)
if err != nil {
http.Error(w, fmt.Sprintf("failed to generate coverage profile: %v", err), http.StatusInternalServerError)
return |
|
Hi @a-nogikh. First of all, just to be sure that our server setup is not creating the problem, I tried to reproduce the problem in a Debian vm on my laptop and I could reproduce the problem. The following is with your patch: |
dvyukov
changed the title
|
Thank you for providing the logs! Now the problem is clear - gcc11 uses DWARF 5, while go 1.14 only supports DWARF 4. It is only starting from go1.16 (golang/go@05b6118#diff-805cfc619792dc0d7fdc727ac0c075475eff2f326d6d33bccd2cd35f8f6ea655) that the dwarf parsing library should begin to handle that normally. Though it's still weird that it all fails that hard. Probably syzkaller should detect DWARF version and only proceed if the library it was compiled with permits it... |
|
Thanks @a-nogikh. So that means there is no immediate fix and I should continue to use gcc-10. But I wonder why I am only seeing this problem. I guess I will try to build syzkaller with latest Update: Trying with new |
In the end I was also able to reproduce it - it turned out that earlier I still used the new go version, while it is the combination of old go version + new gcc version that was vital to trigger the problem :)
What went wrong? You could also try to just check out the repo and execute |
|
Hi @a-nogikh. It has worked. I installed |
We had been running syzkaller for almost last 6 months without any problem. But since last few weeks we started seeing a
syzkaller panic with nil pointer dereferencejust few hours after starting syzkaller. I have then updated syzkaller to 75b0409 but the same problem still persists.I have now run syzkaller with
-debugand I think this is the relavant part of the log:Go version is 1.14.2 and
https://dl.google.com/go/go1.14.2.linux-amd64.tar.gzhas been used as mentioned in the docs.Host is a docker image based on Debian Bullseye.
Target is a x86_64 vm image based on Debian Bullseye.
I will be happy to provide any additional debug logs (if needed).
The text was updated successfully, but these errors were encountered: