Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

runtime: "runtime·lock: lock count" fatal error when cgo is enabled [1.19 backport] #56309

Closed
gopherbot opened this issue Oct 18, 2022 · 2 comments · Fixed by moby/moby#44388, docker/docker-ce-packaging#781, docker/cli#3850 or kata-containers/kata-containers#5774
Closed

runtime: "runtime·lock: lock count" fatal error when cgo is enabled [1.19 backport] #56309

gopherbot opened this issue Oct 18, 2022 · 2 comments · Fixed by moby/moby#44388, docker/docker-ce-packaging#781, docker/cli#3850 or kata-containers/kata-containers#5774
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Milestone
Go1.19.3

Comments

@gopherbot
Copy link

@prattmic requested issue #56243 to be considered for backport to the next 1.19 minor release.

@gopherbot Please backport to 1.18 and 1.19

This issue is not new but can cause random memory corruption in any program that has a goroutine exit with LockOSThread set.
@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Oct 18, 2022
@gopherbot gopherbot mentioned this issue Oct 18, 2022
Closed
@gopherbot gopherbot added this to the Go1.19.3 milestone Oct 18, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Oct 18, 2022
@gopherbot
Copy link
Author

Change https://go.dev/cl/443815 mentions this issue: [release-branch.go1.19] runtime: always keep global reference to mp until mexit completes

@dr2chase dr2chase added the CherryPickApproved Used during the release process for point releases label Oct 19, 2022
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Oct 19, 2022
@hawkingrei hawkingrei mentioned this issue Oct 20, 2022
Closed
@gopherbot
Copy link
Author

Closed by merging 0cc20ec to release-branch.go1.19.

gopherbot pushed a commit that referenced this issue Oct 24, 2022
@prattmic @heschi
[release-branch.go1.19] runtime: always keep global reference to mp u…
0cc20ec 
…ntil mexit completes

Ms are allocated via standard heap allocation (`new(m)`), which means we
must keep them alive (i.e., reachable by the GC) until we are completely
done using them.

Ms are primarily reachable through runtime.allm. However, runtime.mexit
drops the M from allm fairly early, long before it is done using the M
structure. If that was the last reference to the M, it is now at risk of
being freed by the GC and used for some other allocation, leading to
memory corruption.

Ms with a Go-allocated stack coincidentally already keep a reference to
the M in sched.freem, so that the stack can be freed lazily. This
reference has the side effect of keeping this Ms reachable. However, Ms
with an OS stack skip this and are at risk of corruption.

Fix this lifetime by extending sched.freem use to all Ms, with the value
of mp.freeWait determining whether the stack needs to be freed or not.

For #56243.
Fixes #56309.

Change-Id: Ic0c01684775f5646970df507111c9abaac0ba52e
Reviewed-on: https://go-review.googlesource.com/c/go/+/443716
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit e252dcf)
Reviewed-on: https://go-review.googlesource.com/c/go/+/443815
Reviewed-by: Austin Clements <austin@google.com>
corhere added a commit to corhere/moby that referenced this issue Nov 1, 2022
@corhere
Update to Go 1.19.3 to address CVE-2022-41716
f9d4589 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Cory Snider <csnider@mirantis.com>
@corhere corhere mentioned this issue Nov 1, 2022
Merged
@hawkingrei hawkingrei mentioned this issue Nov 4, 2022
Merged
12 tasks
thaJeztah added a commit to thaJeztah/cli that referenced this issue Nov 5, 2022
@thaJeztah
Update to Go 1.19.3 to address CVE-2022-41716
85eee32 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah added a commit to thaJeztah/docker-ce-packaging that referenced this issue Nov 5, 2022
@thaJeztah
Update to Go 1.19.3 to address CVE-2022-41716
63e5da9 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah mentioned this issue Nov 5, 2022
Merged
thaJeztah added a commit to thaJeztah/docker-ce-packaging that referenced this issue Nov 5, 2022
@thaJeztah
[20.10] update to Go 1.18.8 to address CVE-2022-41716
2268f07 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah mentioned this issue Nov 5, 2022
Merged
thaJeztah added a commit to thaJeztah/cli that referenced this issue Nov 5, 2022
@thaJeztah
[20.10] update to Go 1.18.8 to address CVE-2022-41716
acc3f99 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was referenced Nov 5, 2022
Merged
Merged
thaJeztah pushed a commit to thaJeztah/docker that referenced this issue Nov 5, 2022
@corhere @thaJeztah
Update to Go 1.19.3 to address CVE-2022-41716
f3e180b 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Cory Snider <csnider@mirantis.com>
(cherry picked from commit f9d4589)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah mentioned this issue Nov 5, 2022
Merged
thaJeztah added a commit to thaJeztah/docker that referenced this issue Nov 5, 2022
@thaJeztah
[20.10] update to Go 1.18.8 to address CVE-2022-41716
0211f9e 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah mentioned this issue Nov 5, 2022
Merged
thaJeztah added a commit to thaJeztah/containerd that referenced this issue Nov 5, 2022
@thaJeztah
[release/1.6] update to Go 1.18.8 to address CVE-2022-41716
303f608 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah added a commit to thaJeztah/containerd that referenced this issue Nov 5, 2022
@thaJeztah
[release/1.5] update to Go 1.18.8 to address CVE-2022-41716
9d9bd10 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was referenced Nov 5, 2022
Merged
Merged
samuelkarp added a commit to moby/moby that referenced this issue Nov 9, 2022
@samuelkarp
Merge pull request #44411 from thaJeztah/22.06_backport_bump_go1.19.3
38152f4 
fixes golang/go#56309
samuelkarp added a commit to moby/moby that referenced this issue Nov 9, 2022
@samuelkarp
Merge pull request #44412 from thaJeztah/20.10_bump_go_1.18.8
4ed81ac 
fixes golang/go#56309
alex-matei added a commit to UiPath/kata-containers that referenced this issue Nov 25, 2022
@alex-matei
build: update golang version to 1.19.3
a8c9b3c 
This Go release fixes golang/go#56309

Fixes kata-containers#5773
Signed-off-by: Alexandru Matei <alexandru.matei@uipath.com>
@alex-matei alex-matei mentioned this issue Nov 25, 2022
Merged
alex-matei added a commit to UiPath/kata-containers that referenced this issue Nov 26, 2022
@alex-matei
build: update golang version to 1.19.3
f8211e6 
This Go release fixes golang/go#56309

Fixes kata-containers#5773
Signed-off-by: Alexandru Matei <alexandru.matei@uipath.com>
alex-matei added a commit to UiPath/kata-containers that referenced this issue Nov 28, 2022
@alex-matei
build: update golang version to 1.19.3
f443b78 
This Go release fixes golang/go#56309

Fixes kata-containers#5773
Signed-off-by: Alexandru Matei <alexandru.matei@uipath.com>
andrew-d pushed a commit to tailscale/go that referenced this issue Dec 7, 2022
@prattmic @andrew-d
[release-branch.go1.19] runtime: always keep global reference to mp u…
e7c4a1d 
…ntil mexit completes

Ms are allocated via standard heap allocation (`new(m)`), which means we
must keep them alive (i.e., reachable by the GC) until we are completely
done using them.

Ms are primarily reachable through runtime.allm. However, runtime.mexit
drops the M from allm fairly early, long before it is done using the M
structure. If that was the last reference to the M, it is now at risk of
being freed by the GC and used for some other allocation, leading to
memory corruption.

Ms with a Go-allocated stack coincidentally already keep a reference to
the M in sched.freem, so that the stack can be freed lazily. This
reference has the side effect of keeping this Ms reachable. However, Ms
with an OS stack skip this and are at risk of corruption.

Fix this lifetime by extending sched.freem use to all Ms, with the value
of mp.freeWait determining whether the stack needs to be freed or not.

For golang#56243.
Fixes golang#56309.

Change-Id: Ic0c01684775f5646970df507111c9abaac0ba52e
Reviewed-on: https://go-review.googlesource.com/c/go/+/443716
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit e252dcf)
Reviewed-on: https://go-review.googlesource.com/c/go/+/443815
Reviewed-by: Austin Clements <austin@google.com>
@mheon mheon mentioned this issue Jan 17, 2023
Closed
thaJeztah pushed a commit to thaJeztah/docker that referenced this issue Feb 13, 2023
@corhere @thaJeztah
Update to Go 1.19.3 to address CVE-2022-41716
0f2b650 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Cory Snider <csnider@mirantis.com>
(cherry picked from commit f9d4589)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah pushed a commit to thaJeztah/docker that referenced this issue Feb 14, 2023
@corhere @thaJeztah
Update to Go 1.19.3 to address CVE-2022-41716
6776e13 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Cory Snider <csnider@mirantis.com>
(cherry picked from commit f9d4589)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah added a commit to thaJeztah/cli that referenced this issue Feb 14, 2023
@thaJeztah
Update to Go 1.19.3 to address CVE-2022-41716
825e260 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 85eee32)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
corhere added a commit to thaJeztah/docker that referenced this issue Feb 24, 2023
@corhere
Update to Go 1.19.3 to address CVE-2022-41716
17e32bb 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Cory Snider <csnider@mirantis.com>
(cherry picked from commit f9d4589)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
corhere added a commit to thaJeztah/docker that referenced this issue Feb 24, 2023
@corhere
Update to Go 1.19.3 to address CVE-2022-41716
52a475e 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Cory Snider <csnider@mirantis.com>
(cherry picked from commit f9d4589)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
corhere added a commit to thaJeztah/docker that referenced this issue Feb 27, 2023
@corhere
Update to Go 1.19.3 to address CVE-2022-41716
4701ca9 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Cory Snider <csnider@mirantis.com>
(cherry picked from commit f9d4589)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
thaJeztah added a commit to thaJeztah/cli that referenced this issue Mar 28, 2023
@thaJeztah
Update to Go 1.19.3 to address CVE-2022-41716
ff13dd3 
    On Windows, syscall.StartProcess and os/exec.Cmd did not properly
    check for invalid environment variable values. A malicious
    environment variable value could exploit this behavior to set a
    value for a different environment variable. For example, the
    environment variable string "A=B\x00C=D" set the variables "A=B" and
    "C=D".

    Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
    issue.

    This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 85eee32)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@golang golang locked and limited conversation to collaborators Oct 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Projects
None yet
Milestone
Go1.19.3
2 participants
@dr2chase @gopherbot