GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel libceph: use-after-free reading the monmap debugfs file during client teardown

CVE-2026-68153Kernel, userspace & hypervisorcurated

Impact

ceph_destroy_client() stopped the monitor client - freeing monc->monmap - before removing the per-client debugfs files, so a concurrent read of the monmap file could enter monmap_show() on freed memory. GPU nodes that mount CephFS for datasets or map RBD images for checkpoints run this code every time a mount goes away. Realistically this is a node-stability bug rather than a tenant escape: debugfs is root-only on any sane configuration, so the party who can trigger it already has the privileges the UAF would buy. The cost is a panic at exactly the wrong moment - during an unmount or teardown, which is often the end of a job or a node drain.

Who can reach it

Local root, or whoever can read /sys/kernel/debug, on a node with a kernel Ceph mount, racing a read of the client's monmap file against unmount or RBD unmap. Not reachable from an unprivileged container that has no debugfs access.

What to do

Update to a stable kernel with the fix and reboot the node. Given the root-only trigger there is little reason to open an emergency window; fold it into the next scheduled kernel roll. If you run monitoring that periodically scrapes /sys/kernel/debug/ceph, that scraping is the realistic trigger - pausing it around planned unmounts is a cheap interim measure.

References

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.