GPU VulnDB

Database/Control plane, storage & DevOps

Linux kernel ceph client: uninitialized ceph_path_info leads to freeing an object from the wrong slab cache

CVSS 7.8CVE-2026-43408Control plane, storage & DevOpscurated

Impact

ceph_mdsc_build_path() only initializes its ceph_path_info argument on success, and several callers added by the r_parent race fix passed an uninitialized struct, then called ceph_mdsc_free_path_info() on the failure path anyway. The published crash shows the freeing of a ceph_inode_info object through names_cache, a wrong-slab-cache free that ends in kernel BUG at mm/slub.c and a dead node; the reporter notes it may be possible to use this for privilege elevation, which is speculation in the record rather than a demonstrated exploit. This lands on GPU fleets that mount CephFS in the kernel for datasets and checkpoints: the path runs on ordinary file opens, so an unlucky or deliberately hostile workload can take out a node whose GPUs are mid-training, and the panic is on the storage client every node shares.

Who can reach it

Local, any user or container process doing filesystem operations on a kernel-mounted CephFS - ceph_open() is in the published trace. No privileges beyond access to the mount; triggering it requires the build-path call to fail, which depends on MDS state and timing.

What to do

Update to a stable kernel with the added zero initializers (four branches carry backports) and reboot the node; the ceph module cannot be reloaded while the filesystem is mounted, so drain first. Fleets that reach Ceph through the FUSE client or an S3/RGW gateway rather than the kernel client are not affected by this id.

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.