GitHub Security Advisory: GHSA-cgrx-mc8f-2prm
Package: github.com/opencontainers/selinux (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following, CWE-363: Race Condition Enabling Link Following
Vulnerable versions: <= 1.12.0
Patched in: 1.13.0

Summary: runc container escape and denial of service due to arbitrary write gadgets and procfs write redirects

Details:
### Impact ###

This attack is primarily a more sophisticated version of CVE-2019-19921, which was a flaw which allowed an attacker to trick runc into writing the LSM process labels for a container process into a dummy `tmpfs` file and thus not apply the correct LSM labels to the container process. The mitigation runc applied for CVE-2019-19921 was fairly limited and effectively only caused runc to verify that when runc writes LSM labels that those labels are actual procfs files.

Rather than using a fake `tmpfs` file for `/proc/self/attr/<label>`, an attacker could instead (through various means) make `/proc/self/attr/<label>` reference a real `procfs` file, but one that would still be a no-op (such as `/proc/self/sched`). This would have the same effect but would clear the "is a procfs file" check. Runc is aware that this kind of attack would be possible (even going so far as to discuss this publicly as "future work" at conferences), and runc is working on a far more comprehensive mitigation of this attack, but this security issue was disclosed before runc could complete this work.

In all known versions of runc, an attacker can trick runc into misdirecting writes to `/proc` to other procfs files through the use of a racing container with shared mounts (runc has also verified this attack is possible to exploit using a standard Dockerfile with `docker buildx build` as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a `tmpfs` or theoretically other methods such as regular bind-mounts.

Note that while `/proc/self/attr/<label>` was the example used above (which is LSM-specific), this issue affect all writes to `/proc` in runc and thus also affects sysctls (written to `/proc/sys/...`) and some other APIs.

#### Additional Impacts ####

While investigating this issue, runc discovered that another risk with these redirected writes is that they could be redirected to dangerous files such as `/proc/sysrq-trigger` rather than just no-op files like `/proc/self/sched`. For instance, the default AppArmor profile name in Docker is `docker-default`, which when written to `/proc/sysrq-trigger` would cause the host system to crash.

When this was discovered, runc conducted an audit of other write operations within runc and found several possible areas where runc could be used as a semi-arbitrary write gadget when combined with the above race attacks. The most concerning attack scenario was the configuration of sysctls. Because the contents of the sysctl are free-form text, an attacker could use a misdirected write to write to `/proc/sys/kernel/core_pattern` and break out of the container (as described in CVE-2025-31133, kernel upcalls are not namespaced and so coredump helpers will run with complete root privileges on the host). Even if the attacker cannot configure custom sysctls, a valid sysctl string (when redirected to `/proc/sysrq-trigger`) can easily cau