GHSA-gmq2-39ff-f5qg json
A failed upgrade may lead to hung goroutines
published 5y ago modified 5y ago
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
### Impact Processes using tableflip may encounter hung goroutines in the parent process, after a failed upgrade.
The Go runtime has annoying behaviour around setting and clearing O_NONBLOCK: exec.Cmd.Start() ends up calling os.File.Fd() for any file in exec.Cmd.ExtraFiles. os.File.Fd() disables both the use of the runtime poller for the file and clears O_NONBLOCK from the underlying open file descriptor.
This can lead to goroutines hanging in a parent process, after at least one failed upgrade. The bug manifests in goroutines which rely on either a deadline or interruption via Close() to be unblocked being stuck in read or accept like syscalls. As far as I can tell we've not experienced this problem in production, so it's most likely quite rare.
### Patches The problem has been fixed in v1.2.2.
### Workarounds None.
### References * https://github.com/cloudflare/tableflip/commit/cae714b289e199db5da5f08af861ea65be6232c0
Patch / fix
Is GHSA-gmq2-39ff-f5qg in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| go | github.com/cloudflare/tableflip | <1.2.2 |
1.2.2 |
References
Sources
- GitHub Advisory GHSA-gmq2-39ff-f5qg
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.