doos/audit/CVE-2022-0492/README.md

# CVE-2022-0492: cgroup v1 release_agent write check missing, root-equivalent container escape

**Scope:** [audit](../README.md) · [README](../../README.md) · [COMPARISON](../../COMPARISON.md) · [docs/RESEARCH](../../docs/RESEARCH.md)

CVSS 7.0 (High). Fixed around Linux 5.17-rc3. Exploited in the wild before disclosure.

## Source

- [The Hacker News coverage](https://thehackernews.com/2022/03/new-linux-kernel-cgroups-vulnerability.html)
- [Sysdig detection writeup](https://sysdig.com/blog/detecting-mitigating-cve-2021-0492-sysdig)

## Relevance to doos

`cgroup_release_agent_write` did not check that the writer held administrative privilege
over the cgroup hierarchy, so a process inside a container (even without CAP_SYS_ADMIN
at the host level, using a user-namespace-mounted cgroupfs) could set a cgroup v1
`release_agent` path and get it executed with host privileges the next time the cgroup
emptied. This is a cgroup v1 feature; doos targets cgroup v2 exclusively
(`src/cgroup.cpp`, `Cgroup::create`/`open` build paths under the unified hierarchy only)
and, more directly, never mounts any `/sys` or cgroupfs into the container at all, so the
file this bug needs to write would not exist inside a doos container regardless of
kernel version.


## What the check does

Attaches a container and checks `/sys/fs/cgroup` is absent (doos mounts no `/sys` inside
the container) and, if for some reason it is present, that no `release_agent` file exists
under it. FAIL only if a writable `release_agent` is actually reachable from inside.


## Caveats

This verifies doos's own mount list, not the kernel: on a kernel still vulnerable to
CVE-2022-0492 but reached through some other route (a bind mount doos does not create),
this check says nothing. It is scoped to what `doos attach` itself can expose.


Run: `make test` in this directory, or `make -C audit test` from the repo root.