fs2/freezer: cgroup.freeze is not reset on freeze timeout (unlike cgroup v1)

[MrWiffer]

Description

Description

In cgroup v2, when waitFrozen() times out (after 10s of polling cgroup.events), the setFreezer() function returns an error but does not reset cgroup.freeze back to 0. This means the kernel may still complete the freeze asynchronously after runc has already reported failure to the caller.

This creates a state inconsistency: the container runtime (e.g., containerd) believes the container is still running (because the freeze call failed), but the kernel eventually freezes the cgroup. Subsequent operations on the container may behave unexpectedly.

Relevant code

https://github.com/opencontainers/cgroups/blob/main/fs2/freezer.go#L41-L51

if _, err := fd.WriteString(stateStr); err != nil {
    return err
}
// Confirm that the cgroup did actually change states.
if actualState, err := readFreezer(dirPath, fd); err != nil {
    return err  // <-- returns without resetting cgroup.freeze to "0"
} else if actualState != state {
    return fmt.Errorf(...)
}

When readFreezer → waitFrozen returns a timeout error, the freeze request (1 written to cgroup.freeze) is left in place.

Comparison with cgroup v1

This was already fixed for cgroup v1 in PR #2774 — when the freeze operation times out or retries are exhausted, the v1 code explicitly writes THAWED back to freezer.state to cancel the pending freeze. The cgroup v2 path was not given equivalent treatment.

Steps to reproduce the issue

Describe the results you received and expected

Expected behavior

When waitFrozen() times out, setFreezer() should write 0 to cgroup.freeze before returning the error, ensuring the kernel does not complete a late freeze that the caller is unaware of.

What version of runc are you using?

1.3.0

Host OS information

PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

Host kernel information

Linux cce-wek1u212-lhcmc3qc 5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

[rata]

Do you have a repro case?

[kolyshkin]

Do you have a repro case?

@MrWiffer ^^^

I am also interested in a repro (or any evidence of) because my current understanding is cgroup v2 is way more bullet-proof than v1 wrt freezer. In other words, I've never seen cgroup v2 freeze to fail. Meaning, the bug is real but more theoretical than practical.