# CVE-2020-16120: Unprivileged overlay + shiftfs read access

> Unprivileged users can read restricted files via overlayfs copy-up in user namespaces, requiring unprivileged user namespaces to be enabled.

- **Severity:** Medium 5.1 (`CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 10 Feb 2021
- **Updated:** 16 Sep 2024
- **Also known as:** AZL-6522, DEBIAN-CVE-2020-16120, GHSA-q6jw-34cj-733v, UBUNTU-CVE-2020-16120

## What is CVE-2020-16120?

CVE-2020-16120 is a medium-severity vulnerability in Canonical Ubuntu Linux, published on 10 Feb 2021. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

Overlayfs did not properly perform permission checking when copying up files in an overlayfs and could be exploited from within a user namespace, if, for example, unprivileged user namespaces were allowed. It was possible to have a file not readable by an unprivileged user to be copied to a mountpoint controlled by the user, like a removable device. This was introduced in kernel version 4.19 by commit d1d04ef ("ovl: stack file ops"). This was fixed in kernel version 5.8 by commits 56230d9 ("ovl: verify permissions in ovl_path_open()"), 48bd024 ("ovl: switch to mounter creds in readdir") and 05acefb ("ovl: check permission to open real file"). Additionally, commits 130fdbc ("ovl: pass correct flags for opening real directory") and 292f902 ("ovl: call secutiry hook in ovl_real_ioctl()") in kernel 5.8 might also be desired or necessary. These additional commits introduced a regression in overlay mounts within user namespaces which prevented access to files with ownership outside of the user namespace. This regression was mitigated by subsequent commit b6650da ("ovl: do not fail because of O_NOATIMEi") in kernel 5.11.

Weakness: CWE-266 (Incorrect Privilege Assignment)

## Which versions are affected by CVE-2020-16120?

It affects 2 products.


Products: Canonical Ubuntu Linux, Linux kernel.

## How do I fix CVE-2020-16120?

Apply the vendor's patch.

## Is CVE-2020-16120 being exploited?

There is no known exploitation of CVE-2020-16120 in the wild and no public exploit code.

## Other vulnerabilities in Canonical Ubuntu Linux

- [CVE-2020-11651](https://insights.sbomify.com/CVE-2020-11651/): SaltStack Salt Authentication Bypass (critical 9.8, exploited in the wild)
- [CVE-2020-7247](https://insights.sbomify.com/CVE-2020-7247/): OpenSMTPD Remote Code Execution (critical 9.8, exploited in the wild)
- [CVE-2019-16928](https://insights.sbomify.com/CVE-2019-16928/): Exim Out-of-bounds Write (critical 9.8, exploited in the wild)
- [CVE-2018-6789](https://insights.sbomify.com/CVE-2018-6789/): Exim Buffer Overflow (critical 9.8, exploited in the wild)
- [CVE-2015-2590](https://insights.sbomify.com/CVE-2015-2590/): Oracle Java SE and Java SE Embedded Remote Code Execution (critical 9.8, exploited in the wild)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2020-16120 and fix it if it is affected.

What it is: CVE-2020-16120 is a medium-severity vulnerability in Canonical Ubuntu Linux, published on 10 Feb 2021. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2020-16120 in the wild and no public exploit code.

Affected product: Canonical Ubuntu Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2020-16120/ (Markdown: https://insights.sbomify.com/CVE-2020-16120/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2020-16120
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2020-16120
- OSV: https://osv.dev/vulnerability/CVE-2020-16120

---
From sbomify Insights: https://insights.sbomify.com/CVE-2020-16120/
Summaries are generated and may contain mistakes; the official description above is the record.