Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile: depth limit reached in type formatting routine #29312
The formatting routines for types use a depth limit as primitive mechanism to detect cycles. For now, increase the limit from 100 to 250 and file #29312 so we don't drop this on the floor. Also, adjust some fatal error messages elsewhere to use better formatting. Fixes #29264. Updates #29312. Change-Id: Idd529f6682d478e0dcd2d469cb802192190602f6 Reviewed-on: https://go-review.googlesource.com/c/154583 Reviewed-by: Brad Fitzpatrick <email@example.com>
An update on this bug:
At Google CTF finals this year a team was able to exploit this behavior and obtain remote code execution without importing any package except for "fmt".
The issue is that some code that was supposedly safe had a memory corruption due to a very deep type.
When there is a very deep type (253 in this case) the compiler generates an incorrect program. In my opinion this should not be the case and it should instead reject the invalid code (after all, the generated program will not work anyways).
This bug has been there for quite a while and the threat model requires a lot of control on the attacker side (almost arbitrary code).
I don't know if this is exploitable by creating the type via reflection but even if it is it would still require the attacker to call arbitrary primitives, which is unlikely.
It would be nice to have this fixed for the next release but I would not say this is a blocker for 1.14.
This is a classic type confusion and definitely a mis-compilation (as well as an amazing CTF trick). It also introduces unsafety which can't be detected by looking for usages of
However, I believe we (rightfully) gave up on this threat model with the removal of "safe" mode in Go 1.12 (5185744), so I agree that this is not a security issue.