GPU VulnDB

Database/Control plane, storage & DevOps

Linux CephFS client: unbounded copy of MDSCapAuth path and fs_name crashes client at mount

UnscoredCVE-2026-89651Control plane, storage & DevOpscurated

Impact

handle_session() copies the match.path and match.fs_name byte strings from a CEPH_SESSION_OPEN message with a bare ceph_decode_copy() and no preceding bounds check, and the enclosing struct_len fields are skipped rather than enforced. A length field up to 4 GiB makes the client read that far past the message front allocation, crashing the node with an out-of-bounds read - reported by KASAN as slab-out-of-bounds in handle_session(). This fires on the first post-connect message at mount time, with no user interaction, so a hostile MDS can take down every client that tries to mount. On a GPU fleet that mounts CephFS for datasets or checkpoints, that is a fleet-wide denial of service triggered by the storage control plane rather than by any tenant.

Who can reach it

A malicious or compromised Ceph MDS responding to a client's session open, or an on-path attacker on an unauthenticated messenger session. No credentials on the client side and no local user needed - the mount itself is the trigger.

What to do

Patch the host kernel to a stable release that switches both copies to ceph_decode_copy_safe() (commits below), then drain and reboot each CephFS client node. Before patching, limit exposure by ensuring clients only reach trusted MDS daemons and by running msgr2 in secure mode so sessions cannot be hijacked on-path. No vendor fixed-version string is given in the record beyond the stable commits.

References

Related entries

All Control plane, storage & DevOps entries

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.