Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
cmd/compile: nil check not scheduled correctly #42673
Note the TESTB which is a nil check. It is redundant with the previous load, which would have faulted if AX is nil.
There are 2 nil checks in this code, but only one is removed (technically, not removed but merged with a load).
This is actually more than a performance bug. The nil checks are not getting scheduled correctly.
This compiles to
The read is happening before its corresponding nil check. The nil check elim pass is doing the right thing. It is the scheduling pass which is wrong.
I don't see an obvious way to defeat type safety with this bug, but it makes me nervous. We should fix it for 1.16.
This is looking trickier than first appears (see CL). I'm going to punt to 1.17.
I think the worst thing that can happen here is that we can read arbitrary parts of memory before a nil fault. In those cases it was going to fault anyway, so maybe we get a SIGBUS instead of a SIGSEGV. That's about as bad as it gets. Perhaps memory-mapped device drivers might treat reads as having side-effects, but that seems like a tiny attack surface.
Possibly also there's some spectre-ish vulnerability here, but without the speculation, if a chain of nilptr-delayed reads can be constructed. I think it would involve some very strange gadgets that would have to be in a binary, though, so it appears unlikely to matter.