Linux Kernel CVE-2026-90042

Requires a mounted CephFS with fscrypt filename encryption in use, so that ceph_fname_to_usr() is invoked on MDS-supplied encrypted names during operations like readdir and lookup. Triggering is probabilistic: it depends on kernel memory fragmentation causing kvmalloc() to place the message buffer in the vmalloc() region rather than the linear kmalloc() region (author measured roughly 1 in 8,000 readdir messages). Impact is markedly more likely on non-x86 platforms. Limiting factors: no encrypted CephFS mount, no fscrypt in use, or sufficient contiguous memory (buffers stay in the linear region) all prevent the oops; there is no attacker-controlled code execution or data disclosure - only a kernel crash.

The vendor CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) badly overstates real-world risk and conflicts with the technical description. This is a crash/oops bug in the CephFS client fscrypt path, not a remote code execution or confidentiality issue: ceph_fname_to_usr() passes kvmalloc()-backed MDS message buffers that may land in the vmalloc() region to the scatterlist-based fscrypt API, which requires linear-mapped memory, causing kernel oopses (explicitly 'especially on non-x86 platforms'). The impact is availability (kernel panic/DoS), so C:H/I:H are not supported by the description - nothing is disclosed or written attacker-controlled. The network vector (AV:N) is also questionable: exploitation requires an already-mounted encrypted CephFS and local filesystem operations (e.g. readdir/lookup) that trigger filename decryption; it is not a remote unauthenticated network primitive. Triggering additionally depends on physical memory fragmentation pushing the buffer into vmalloc (author measured ~1 in 8,000 readdir messages), making it probabilistic rather than reliably triggerable (AC:H). There is no EPSS, no KEV entry, no CWE, and no public POC - no public exploit identified at time of analysis. Net: this is a genuine stability bug worth patching on affected CephFS deployments but is a high-CVSS-but-low-real-risk item, not an urgent widely-exploitable priority. My independent estimate is roughly 4.7 (AV:L/AC:H/PR:L/C:N/I:N/A:H).

On a host with an encrypted (fscrypt) CephFS mount, a local user or workload performs directory listings and filename lookups; occasionally, under memory fragmentation, an MDS reply buffer is allocated in the vmalloc() region and its encrypted filename is handed to the scatterlist crypto API, oopsing the kernel and crashing the machine (most readily on non-x86 platforms). No public exploit code exists; the referenced 'Closes:' reproducer demonstrates the crash but requires the specific encrypted-CephFS deployment and fragmentation conditions.