GPU VulnDB

Database/Control plane, storage & DevOps

Linux CephFS client: out-of-bounds read decoding MDS map info v2/v3 export targets

UnscoredCVE-2026-89650Control plane, storage & DevOpscurated

Impact

ceph_mdsmap_decode() advances the decode cursor by num_export_targets * 4 bytes without checking that many bytes remain, and the only guard that would catch the runaway cursor is gated on info version 4 or higher. A monitor that sends an MDS map with per-mds info version 2 or 3 and an oversized count drives an out-of-bounds read in the client kernel, reported under KASAN as a slab-out-of-bounds in ceph_mdsmap_decode(). The decoded values land in an internal array, so the result is a client kernel crash rather than a leak to the attacker - but a crash here takes down every CephFS mount on the node, which on a GPU node means killing in-flight training jobs and forcing a reboot. MDS maps arrive unsolicited from the monitor session, so no tenant action is needed to trigger it.

Who can reach it

A malicious or compromised Ceph monitor, or an on-path attacker on an unsigned and unencrypted messenger session, sending a crafted CEPH_MSG_MDS_MAP to a mounting client. No client-side authentication or user interaction required.

What to do

Patch the host kernel to a stable release carrying the added ceph_decode_need() and size_mul() bound in ceph_mdsmap_decode() (commits below), then drain and reboot each node mounting CephFS. Interim mitigation is restricting which monitors clients can reach and running msgr2 in secure mode so an on-path attacker cannot forge the map. The record names no vendor fixed-version string 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.