/ go Public
x/sys/unix: Capget/Capset writes past struct's memory #44312
Issues related to the Go compiler and/or runtime.
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
I have a go program that is using unix.Capget/Capset and was randomly crashing.
Thanks to @ianlancetaylor this code was identified as a culprit:
Turns out that version 2 and version 3 linux capabilities are wider than version 1 capabilities.
Version 1 uses 32bit fields and fit perfectly into a single
However version 2 and version 3 capabilities are 64 bit and do not fit into a single
Instead of using a struct with wider fields however linux capget syscall uses the same struct but writes into 2 instances of the struct. It writes lower bits of the capabilities into the first struct and the higher bits into the second one.
So, confusingly the correct way of writing the code above would be:
Which is normal practice in C, but doesn't look like a typical go to me.
This code would write lower bits into
dataand higher bits into
data. Then the client would have to be careful when setting capabilities, choosing
datadepending on the capability, for example:
Same applies to unix.Capset, except it would read past the first struct.
I'm wondering if the signature of
unix.Capget/Capsetshould be changed into something like:
to prevent issues like this. Such a signature would clearly indicate the amount of memory affected by the syscall.
Or maybe make the fields wider and repack during the call to account for a weird memory layout? That wouldn't work very well though if linux keeps expanding capabilities and would go even wider.
The text was updated successfully, but these errors were encountered: