| commit | d6a88022d0c8ffdd2b938f161b8825148762b099 | [log] [tgz] |
|---|---|---|
| author | Jan Schär <jan@jschaer.ch> | Mon Mar 18 17:03:37 2024 +0100 |
| committer | Jan Schär <jan@jschaer.ch> | Mon Mar 18 17:24:36 2024 +0000 |
| tree | a5a0e0c0b1e6970c1aef8a38e2b45978c00b8592 | |
| parent | 42ef7c742ab128b25478833a52af25ba0be5bf15 [diff] |
m/node: fix appending to read-only slices
`append` modifies its first argument if there is sufficient capacity
instead of allocating a new slice. If the slice to be appended to is
supposed to be read-only, this can lead to unexpected aliasing.
An example of what can go wrong, here with the consensus client:
l := NewLocal(nil)
sub1, _ := l.Sub("I")
sub2, _ := sub1.Sub("am")
sub3, _ := sub2.Sub("a")
dog, _ := sub3.Sub("dog")
_, _ = sub3.Sub("cat")
fmt.Print(dog.(*local).path)
Result before this change: "I am a cat"
Result after this change: "I am a dog"
After creating a subnamespace of length 3, the capacity of the `path` is
4, so any subnamespace will share the same slice. The fix is to always
ensure a new slice is allocated.
Impact
------
For the consensus client, Sub is currently never called multiple times
on the same namespace, so there is no impact there. In case of the dhcp
client and rpc resolver, the slices that are appended to are slice
literals in all cases, which don't have extra capacity.
But for the curator `etcdPrefix`, `p.parts` has capacity 1 larger than
the length, due to the slicing in `newEtcdPrefix`. That means that
concurrent calls to `Key` can overwrite each other's `path`. It looks
like `Key` can in fact be called concurrently, which means there is
potential for data corruption to occur before this change.
Change-Id: I28e7dc797365c2beea97023ed31a20eea599e678
Reviewed-on: https://review.monogon.dev/c/monogon/+/2873
Vouch-Run-CI: Lorenz Brun <lorenz@monogon.tech>
Tested-by: Jenkins CI
Reviewed-by: Serge Bazanski <serge@monogon.tech>
This is the main repository containing the source code for the Monogon Platform.
This is pre-release software - take a look, and check back later!
Our build environment is self-contained and requires only minimal host dependencies:
/dev/kvm (if you want to run tests).Our docs assume that Bazelisk is available as bazel on your PATH.
Refer to SETUP.md for detailed instructions.
The source code lives in //metropolis (Metropolis is the codename of Monogon OS).
See the //metropolis/README.md for a developer quick start guide, or see the Monogon OS Handbook for user documentation.