GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel CephFS client: punch-hole writes without snapshot context silently corrupt existing snapshots

CVSS 5.5CVE-2026-43273Kernel, userspace & hypervisorcurated

Impact

ceph_zero_partial_object() issued its OSD write operations without supplying a snapshot context, so a hole punched in a live file is applied to data that an existing snapshot should still own. The reproducer in the fix is unambiguous: take a snapshot, fallocate -p the file, drop caches, and the snapshot's checksum changes. For a cluster using CephFS as shared training-data or checkpoint storage this is silent data integrity loss in exactly the copies you keep for recovery - a snapshot you would restore from no longer holds what it did when taken. No privilege boundary is crossed; any tenant that can write to a CephFS mount and whose files are snapshotted can trigger it, including by accident.

Who can reach it

Local, through a mounted CephFS filesystem. Any user with write access to a file on that mount (normal POSIX permissions) can trigger it with fallocate; no elevated privilege and no network access to the cluster is needed.

What to do

Update the kernel on every CephFS client - this is the kernel client, not the Ceph server side, so patching the MDS/OSDs changes nothing. Clients need the stable kernel update and a reboot (or at minimum unmount, module reload, remount, which on a busy GPU node means draining the jobs holding the mount). Treat snapshots taken on an unpatched client as suspect; the fix prevents new divergence and does not repair snapshots already damaged.

References

Related entries

All Kernel, userspace & hypervisor 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.