About the gosec G115 drama, or how I faced back integer conversion overflow in Go

Go is a strongly typed language, it avoids making mistakes.

I wrongly assumed Go was handling integer overflows, and reported an error.

Here is the perfect world where everything works as expected

a := int64(42)
b := uint8(a)
fmt.Println(b) // 42
Enter fullscreen mode
Exit fullscreen mode

So what does the following code

a = 255 + 1 // 255 is the higher value an uint8 can reach
b = uint8(a)
fmt.Println(b) // ? a = -1
b = uint8(a)
fmt.Println(b) // ?
Enter fullscreen mode
Exit fullscreen mode

Here is the solution

Spoiler: it doesn’t work as expected, or at least as we could expect.

So here Go is doing a silent conversion, of course it cannot store the value in the integer types provided, but there is no error at all.

There are consequences: CWE-190

  • Imagine you access a resource by its identifier, but you need to convert from an integer type to another, you may allow to access to another resource.

Because of this, gosec a linter focused on improving the security in Go, provided a linter to detect the issue: the linter G115

The G115 linter idea was good.

But it was unfortunately merged with some false issues, that are now addressed, except a few ones.

The problem becomes massive after gosec v2.21.0 was merged into golangci-lint

Many people disabled gosec G115, because of the false positives and noise it was bringing to the CI

So now many people unfortunately disabled the G115 checker, you can see it easily on GitHub


Discover more from Coursity

Subscribe to get the latest posts sent to your email.

Leave a Comment

Your email address will not be published. Required fields are marked *

Discover more from Coursity

Subscribe now to keep reading and get access to the full archive.

Continue reading

Scroll to Top
Essential skills for web developer success. Screen reader users also get automatic announcements to turn the screen reader mode on as soon as they enter the website.