CVE-2026-90042

The Ceph filesystem client in the Linux kernel allocates message buffers with kvmalloc(), which can fall back to vmalloc() memory when fragmentation prevents a large contiguous allocation, but ceph_fname_to_usr() passed these raw MDS reply buffers to the fscrypt scatterlist crypto API, which only accepts linear-mapping addresses. When a readdir/metadata reply from the Ceph metadata server lands in a vmalloc() buffer on a CephFS mount with filename encryption enabled, the kernel hits an invalid address and oopses; the reporter's testing hit this on roughly 1 in 8,000 readdir messages, with crashes most likely on non-x86 architectures. An attacker who controls or can spoof the Ceph metadata server, or can intercept client-cluster traffic, can therefore trigger kernel crashes — a denial of service; despite the CNA's 9.8 network-vector score, the advisory describes oopses rather than demonstrated code execution or data theft. Only Linux systems using the kernel CephFS client with fs-encryption (encrypted filenames) are affected. No in-the-wild exploitation or public PoC is known, although the fix commit references a reproducer, and the fix routes vmalloc() addresses through a linear bounce buffer.

What to do: Update Linux systems that mount CephFS with encryption to a kernel containing the 'ceph: properly decrypt filenames in vmalloc() buffers' commit (latest mainline/stable, or your vendor's backport once released). As an interim mitigation, disable filename encryption on CephFS mounts and restrict which hosts can reach or impersonate the Ceph monitors/MDS, since a malicious or on-path metadata server is required to trigger the flaw. Audit your fleet for CephFS mounts using fscrypt to confirm whether you are in the affected population.