VulnTideExploited vulnerabilities, by vendor. Data as of .
Not in CISA KEVPublished CVSS 9.8 criticalEPSS 0.5% probability of exploitation in 30 days
Linux

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

Is it exploited?

Not on CISA's list. CISA has not added it to the Known Exploited Vulnerabilities catalog as of . If CISA adds it, this page shows it as known exploited.

How likely is exploitation in the next 30 days?
0.5%

EPSS score, percentile 42.9 of all scored records. A probability estimated by FIRST, not a report of exploitation.

How severe?
9.8 Critical

CVSS v3.1 base score, given by the CNA

What should I do?

CISA has set no required action, because the vulnerability is not in KEV.

The CVE record links no vendor advisory, patch or mitigation.

Which versions are affected?

Affected

  • 6.6

Unaffected before 6.6; 6.6.160; 6.12.111; 6.18.51; 7.2.5; 7.3

Versions by product

Source: CISA KEV 2026.10.29, as of ; FIRST EPSS, as of ; CVE List, as of . About the data.

What to do

Advisories and patches

The CVE record links no vendor advisory, patch or mitigation.

This summary is based on the CVE record as of . Check the vendor's advisory before you act: affected versions and fixes can change.

Affected products and versions

As listed in the CVE record.

Linux Linux
StatusVersions
Affectedfrom 457117f077c6 to before 23c5cc9652c6
Affectedfrom 457117f077c6 to before 93729594af50
Affectedfrom 457117f077c6 to before 110747ff535e
Affectedfrom 457117f077c6 to before 3b467c68803d
Affectedfrom 457117f077c6 to before e939fc6a7bd9

Versions not listed are: unaffected.

Linux Linux
StatusVersions
Affected6.6
Unaffectedbefore 6.6
Unaffected6.6.160
Unaffected6.12.111
Unaffected6.18.51
Unaffected7.2.5
Unaffected7.3

Versions not listed are: affected.

Versions the record lists as unaffected: 6.6.160, 6.12.111, 6.18.51, 7.2.5, 7.3.

Source: CVE List, as of . About the data.

About this vulnerability

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() reg…

Summary: CVE record, as of .

  • CISA has not added CVE-2026-90042 to its Known Exploited Vulnerabilities (KEV) catalog, as of 29 Oct 2026.
  • The CVE record was published on 16 Sep 2026.
  • The CVE record carries a CVSS v3.1 base score of 9.8 (Critical), given by its CNA.
  • FIRST's EPSS model puts the probability of exploitation in the next 30 days at 0.5% (percentile 42.9), as of 29 Oct 2026. EPSS is a statistical estimate, not a report of exploitation.

Source: CISA KEV 2026.10.29, as of ; CVE List, as of ; FIRST EPSS, as of . About the data.

Description

ceph: properly decrypt filenames in vmalloc() buffers

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.

Source: CVE List, as of . About the data.

Timeline

DateEvent
CVE record published
CVE record last updated

References

5

Known exploited Linux vulnerabilities

  • CVE-2026-46300: Linux Kernel Missing Initialization of a Variable Vulnerability (added )
  • CVE-2025-39682: Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability (added )
  • CVE-2025-39964: Linux Kernel Race Condition Vulnerability (added )
  • CVE-2026-53266: Linux Kernel Out-of-Bounds Write Vulnerability (added )
  • CVE-2026-53362: Linux Kernel Unspecified Vulnerability (added )