GPU VulnDB

Database/Control plane, storage & DevOps

Linux kernel ceph client: use-after-free when trimming caps concurrently with cap removal

CVSS 9.8CVE-2023-53867Control plane, storage & DevOpscurated

Impact

A race between cap trimming and concurrent cap removal left ceph_iterate_session_caps() using freed cap memory in its callbacks, crashing the client. This hits GPU nodes that mount CephFS in-kernel for datasets, checkpoints or shared home directories: the fault is on the compute node, so a trim storm under memory pressure takes down a node running tenant jobs rather than the storage cluster. The record describes a timing-dependent use-after-free fixed by re-checking cap existence under i_ceph_lock, with no evidence of a controllable exploit primitive - read it as availability risk on mounted clients.

Who can reach it

Local, and not directly attacker-driven: triggered by kernel cap trimming racing MDS-driven cap removal on a node with a CephFS mount. No tenant action is required, and no authentication boundary is crossed.

What to do

Apply the stable kernel update carrying the fix (commits in the record) and reboot each affected node; drain GPU nodes first, since an in-kernel CephFS mount cannot be replaced without unmounting. No mitigation short of the patch other than avoiding kernel CephFS mounts on compute nodes.

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.