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).
Looking at the code, I think it is because the two nil checks get scheduled out of order, so the elimination code gets confused. The elimination code should be more robust to ordering.
The text was updated successfully, but these errors were encountered:
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.