Database/Control plane, storage & DevOps

Linux kernel libceph: unbounded auth key length overflows a fixed-size buffer in process_auth_done()

CVSS 9.8CVE-2026-43304Control plane, storage & DevOpscurated

Impact

The in-kernel Ceph client did not bound the length of key material decoded during authentication before copying it into a fixed-size buffer in process_auth_done(). A malicious or compromised Ceph monitor, or anyone able to answer on the monitor's behalf on the storage network, can return an oversized key and corrupt kernel memory on the client. On GPU nodes this matters wherever CephFS or RBD is mounted in-kernel for datasets and checkpoints: the client is the compute node itself, so corruption lands on a node that is holding tenant workloads. The record does not demonstrate a working exploit beyond the memory-safety fix, so treat the realistic outcome as client-side kernel instability with memory corruption potential.

Who can reach it

Requires the ability to act as, or sit in the path of, the Ceph monitor that a kernel CephFS/RBD client talks to - i.e. presence on the storage network. No credentials on the client node itself.

What to do

Take the stable kernel update that adds the CEPH_MAX_KEY_LEN check (commits linked in the record); the fix is in the kernel, so each node needs a reboot after patching - drain the GPU node first since in-kernel Ceph mounts cannot be hot-swapped. No vendor-stated workaround; restricting the storage network so only trusted monitors are reachable reduces exposure in the meantime.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-43304 https://git.kernel.org/stable/c/1b275bd49e58752efb83767a5d1aed41356c5e64 https://git.kernel.org/stable/c/6405e8c680974bb74e2c98d5249fb52c7b12a6c6

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.