Linux kernel CephFS client: oops decrypting filenames from vmalloc() message buffers

CVSS 9.8CVE-2026-90042Kernel, userspace & hypervisorcurated

Impact

The ceph messenger allocates message buffers with kvmalloc(), which falls back to the vmalloc() region when physical memory is fragmented, but ceph_fname_to_usr() hands those buffers straight to fscrypt, whose scatterlist crypto API requires linear-mapping addresses. On an encrypted CephFS, a readdir or lookup whose reply landed in vmalloc() memory oopses the kernel, reported as especially reachable on non-x86 (arm64) platforms. The practical effect is a denial of service on the node, not memory disclosure. It is more likely on long-lived, memory-fragmented machines - which describes a GPU node after weeks of large allocations - and it takes down the host, so every job resident on that node dies with it.

Who can reach it

Local - any process that can read directories on an fscrypt-encrypted kernel CephFS mount. No authentication beyond access to the mount; triggering depends on host memory fragmentation, so it is not reliably attacker-controlled.

What to do

Apply the stable-kernel update containing the three listed commits and reboot each node with an encrypted CephFS mount. Until then, the exposure is limited to encrypted CephFS mounts, so unmounting those or using unencrypted mounts avoids the path. No fixed distribution version is given in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-90042 https://git.kernel.org/stable/c/110747ff535e3d98ac17d68dbd056bb6ef000e23 https://git.kernel.org/stable/c/3b467c68803d7c7e82678289e598afd44faa6101 https://git.kernel.org/stable/c/e939fc6a7bd969a58a150b7f188c1047138403e3

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.