COcodys·Dec 26, 2025
Here's an example where a bug could exist in go due torn writes in a real program.
I found this by searching for places where folks reload there config at runtime, as they are generally a place where people forget to synchronize correctly in go.
1. A viper.OnConfigChange callback is set up to call readConfig(): https://github.com/OdyseeTeam/chainquery/blob/48c092515dea5c...
2. Inside readConfig(), we assign to a slice `twillio.RecipientList` (https://github.com/OdyseeTeam/chainquery/blob/48c092515dea5c...
3. Note that in Go, slices are objects composed of 3 words (https://go.dev/blog/slices-intro#slice-internals) And there isn't syncronization built-in over updating them. As a result, if something reads the slice while it's being updated we will mix together a data pointer & length & capacity that correspond to different real slice object
Read the rest
s. If the length we read is from a slice that has real length 10, but the data pointer we read is from a slice with real length 1, when iterating we'll read memory out of bounds.
4. in the context of this particular program, we may send SMSs to recipients who were never in the configured list if a config change occurs at the right time. Or a segfault. Entirely unclear if reading the memory will result in reasonable behavior.
Note: I'm not familiar with this repo otherwise. This is from a quick search.