diff: opencontainers/runc@v1.1.13...v1.1.14

Release Notes:

- Fix CVE-2024-45310, a low-severity attack that allowed
  maliciously configured containers to create empty files and directories on
  the host.
- Add support for Go 1.23.
- Revert "allow overriding VERSION value in Makefile" and add EXTRA_VERSION.
- rootfs: consolidate mountpoint creation logic.

Signed-off-by: Akhil Mohan <[email protected]>
(cherry picked from commit 299a971)
Signed-off-by: Akhil Mohan <[email protected]>

[release/1.7] update runc binary to 1.1.14

During removal of the container a stat value might be reported as zero; in this case the caluclation could end up with an extremely large number.  If the cumulative stat decreases report zero.

Signed-off-by: James Sturtevant <[email protected]>
(cherry picked from commit f6677a4)
Signed-off-by: James Sturtevant <[email protected]>

Signed-off-by: James Sturtevant <[email protected]>

[release/1.7] Cumulative stats can't decrease

It's not true that `s.mu` needs to be held when calling
`handleProcessExit`, and indeed hasn't been the case for a
while – see 892dc54.

Signed-off-by: Laura Brehm <[email protected]>
(cherry picked from commit 7f3bf99)
Signed-off-by: Laura Brehm <[email protected]>

The runc task state machine prevents execs from being created after the
init process has exited, but there are no guards against starting a
created exec after the init process has exited. That leaves a small
window for starting an exec to race our handling of the init process
exiting. Normally this is not an issue in practice: the kernel will
atomically kill all processes in a PID namespace when its "init" process
terminates, and will not allow new processes to fork(2) into the PID
namespace afterwards. Therefore the racing exec is guaranteed by the
kernel to not be running after the init process terminates. On the other
hand, when the container does not have a private PID namespace (i.e. the
container's init process is not the "init" process of the container's
PID namespace), the kernel does not automatically kill other container
processes on init exit and will happily allow runc to start an exec
process at any time. It is the runc shim's responsibility to clean up
the container when the init process exits in this situation by killing
all the container's remaining processes. Block execs from being started
after the container's init process has exited to prevent the processes
from leaking, and to avoid violating the task service's assumption that
an exec can be running iff the init process is also running.

Signed-off-by: Cory Snider <[email protected]>
(cherry picked from commit e735791)
Signed-off-by: Laura Brehm <[email protected]>

This commit rewrites and simplifies a lot of this logic to reduce it's
complexity, and also handle the case where the container doesn't have
it's own pid-namespace, which means that we're not guaranteed to receive
the init exit last.

This is achieved by replacing `s.pendingExecs` with `s.runningExecs`,
for which both (previously) pending and de facto running execs are
considered.

The new exit handling logic can be summed up by:
- when we receive an init exit, stash it it in `s.containerInitExit`,
  and if a container's init process has exited, refuse new execs.
- (if the container does not have it's own pidns) kill all running
  processes (if the container has a private pid-namespace, then all
  processes will be dead already).
- wait for the container's running exec count (which includes execs
  which have been started but might still early exit) to get to 0.
- publish the stashed away init exit.

Signed-off-by: Laura Brehm <[email protected]>
(cherry picked from commit 421a4b5)
Signed-off-by: Laura Brehm <[email protected]>

- https://github.com/golang/go/issues?q=milestone%3AGo1.27.7+label%3ACherryPickApproved
- full diff: golang/go@go1.22.6...go1.22.7

These minor releases include 3 security fixes following the security policy:

- go/parser: stack exhaustion in all Parse* functions

    Calling any of the Parse functions on Go source code which contains
    deeply nested literals can cause a panic due to stack exhaustion.

    This is CVE-2024-34155 and Go issue https://go.dev/issue/69138.

- encoding/gob: stack exhaustion in Decoder.Decode

    Calling Decoder.Decode on a message which contains deeply nested
    structures can cause a panic due to stack exhaustion.

    This is a follow-up to CVE-2022-30635.

    Thanks to Md Sakib Anwar of The Ohio State University for reporting
    this issue.

    This is CVE-2024-34156 and Go issue https://go.dev/issue/69139.

- go/build/constraint: stack exhaustion in Parse

    Calling Parse on a "// +build" build tag line with deeply nested
    expressions can cause a panic due to stack exhaustion.

    This is CVE-2024-34158 and Go issue https://go.dev/issue/69141.

View the release notes for more information:
https://go.dev/doc/devel/release#go1.22.7

Signed-off-by: Sebastiaan van Stijn <[email protected]>

[release/1.7] update to go1.22.7, go1.23.1

…it-exits

[1.7 backport] Fix bug where init exits were being dropped

Signed-off-by: Samuel Karp <[email protected]>
(cherry picked from commit 5f37a2c)
Signed-off-by: Samuel Karp <[email protected]>

This issue was caused by a race between init exits and new exec process
tracking inside the shim. The test operates by controlling the time
between when the shim invokes "runc exec" and when the actual "runc
exec" is triggered. This allows validating that races for shim state
tracking between pre- and post-start of the exec process do not exist.

Relates to #10589

Signed-off-by: Samuel Karp <[email protected]>
(cherry picked from commit 18725f0)
Signed-off-by: Samuel Karp <[email protected]>

[release/1.7] integration: regression test for issue 10589

Signed-off-by: Samuel Karp <[email protected]>

Prepare release notes for v1.7.22