# CVE-2026-90042: ceph: properly decrypt filenames in vmalloc() buffers

> A kernel bug in Ceph filesystem handling causes crashes when processing filenames in vmalloc buffers, leading to denial of service.

- **Severity:** Critical 9.8 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 16 Sep 2026
- **Updated:** 21 Oct 2026
- **Also known as:** AZL-101199, BELL-CVE-2026-90042, DEBIAN-CVE-2026-90042, GHSA-39q8-gjm7-pm22, UBUNTU-CVE-2026-90042

## What is CVE-2026-90042?

CVE-2026-90042 is a critical vulnerability in Linux, published on 16 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

In the Linux kernel, the following vulnerability has been resolved:

ceph: properly decrypt filenames in vmalloc() buffers

The fscrypt subsystem uses the scatterlist crypto API, inheriting its
requirement that any buffers are in the linear mapping region. However,
the messenger client uses kvmalloc() to create buffers for messages,
which will occasionally place those buffers in the vmalloc() region when
physical memory fragmentation doesn't permit a large enough kmalloc().
The various callers of ceph_fname_to_usr() directly pass (slices of) raw
messages from the MDS without considering that the messages may be in
vmalloc() buffers, resulting in oopses especially on non-x86 platforms
(see 'Closes:' for more details and a reproducer).

Make ceph_fname_to_usr() explicitly tolerant of vmalloc()-allocated
fname->ctext, fname->name, and/or oname->name buffers, using `tname`
(which, when non-null, must be a linear address; when null, is briefly
allocated as necessary) as a bounce buffer to avoid passing any
inappropriate addresses to fscrypt_fname_disk_to_usr().

Additionally change parse_reply_info_readdir() -- the only function to
supply its own `tname` -- to follow the new "tname must never come from
vmalloc()" rule by passing NULL when the message is not in the linear
region. Though this causes a per-dentry kmalloc()+kfree(), this overhead
exists only when processing the minority of messages that spill into
vmalloc(). My (crude) testing puts this at only about 1 in 8,000 readdir
messages. Still, if the overhead proves unreasonable in the future, it
is easy enough to mitigate: a future change could allocate a bounce
buffer in parse_reply_info_readdir() and use that as `tname` instead.

## Which versions are affected by CVE-2026-90042?


## How do I fix CVE-2026-90042?

Apply the vendor's patch.

## Is CVE-2026-90042 being exploited?

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

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-90042 and fix it if it is affected.

What it is: CVE-2026-90042 is a critical vulnerability in Linux, published on 16 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-90042 in the wild and no public exploit code.

Affected product: 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-2026-90042/ (Markdown: https://insights.sbomify.com/CVE-2026-90042/index.md)
```

## Sources

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

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