CVE-2026-43273: Linux Kernel Information Disclosure Flaw

CVE-2026-43273 Overview

CVE-2026-43273 is a Linux kernel vulnerability in the CephFS client. The ceph_zero_partial_object() function failed to supply a snapshot context when issuing Object Storage Daemon (OSD) write operations. This omission allowed punch-hole operations on a live file to alter data already captured in a prior snapshot, breaking snapshot immutability guarantees.

The defect surfaces during operations such as fallocate -p (punch hole) on files that already exist in a CephFS snapshot. Without the correct SnapContext, the OSD treats the zeroing write as part of the head object rather than creating a clone, which corrupts the snapshot view of the file.

Critical Impact

Reading a file from a CephFS snapshot can return data that differs from the snapshot's original contents, undermining backup integrity and point-in-time recovery.

Affected Products

• Linux kernel CephFS client (fs/ceph)
• Distributions shipping affected stable kernels prior to the fix commits
• Workloads mounting CephFS with snapshots enabled (.snap directories)

Discovery Timeline

• 2026-05-06 - CVE-2026-43273 published to the National Vulnerability Database (NVD)
• 2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43273

Vulnerability Analysis

The vulnerability resides in the CephFS kernel client function ceph_zero_partial_object(), which is invoked when userspace requests a partial-object zero through paths such as fallocate(FALLOC_FL_PUNCH_HOLE). The function constructs an OSD write request to zero a byte range but omits the file's current snapshot context (ceph_snap_context).

In Ceph, every write must carry a SnapContext so the OSD can decide whether to clone the existing object before applying the mutation. When the context is missing or incorrect, the OSD performs the write directly against the head object and never preserves the prior content for snapshots that should still reference it. The result is silent divergence between the snapshot's expected contents and what the OSD returns when the snapshot is read.

The kernel commit log includes a deterministic reproducer using vstart.sh, dd, mkdir /mnt/mycephfs/.snap/snap1, and fallocate -p. After dropping caches, md5sum of the file inside the snapshot changes, confirming snapshot data has been mutated.

Root Cause

The root cause is a missing parameter: ceph_zero_partial_object() did not pass the inode's active ceph_snap_context to the OSD request builder. Other CephFS write paths correctly attach the snapshot context, but this code path was overlooked, classifying the issue as a state-handling defect in snapshot-aware I/O.

Attack Vector

Exploitation requires a local user with write access to a CephFS mount where snapshots exist. Issuing a punch-hole fallocate against a file that has been captured in a snapshot causes the snapshot's copy of that file to be silently corrupted. The vulnerability does not yield code execution or privilege escalation; the impact is integrity loss for snapshot data and any backup or compliance workflow that relies on it.

The vulnerability manifests through standard filesystem syscalls and requires no special tooling. See the upstream fix in Linux Kernel Commit 9efa1546 and related stable backports for the precise code change.

Detection Methods for CVE-2026-43273

Indicators of Compromise

• Checksum mismatches between a CephFS snapshot file and a known-good baseline of the same snapshot
• fallocate or hole-punching activity against files that are also present under .snap/ directories on vulnerable kernels
• Backup verification jobs reporting unexpected differences in files that should be immutable within a snapshot

Detection Strategies

• Compare file hashes inside .snap/<snapname>/ against externally stored reference hashes captured at snapshot creation time
• Audit running kernel versions across CephFS clients and flag hosts that lack the fix commits referenced in the NVD entry
• Correlate Ceph OSD logs for write operations on objects belonging to snapshotted inodes from clients running vulnerable kernels

Monitoring Recommendations

• Enable kernel version inventory collection on all CephFS clients and alert on hosts running pre-patch builds
• Monitor fallocate syscall telemetry on CephFS mounts using auditd or eBPF-based observability
• Track snapshot integrity by scheduling periodic checksum verification of files within .snap/ directories

How to Mitigate CVE-2026-43273

Immediate Actions Required

• Apply the upstream Linux kernel patch series referenced in the NVD entry to all CephFS client hosts
• Reboot affected systems after kernel update so the fixed ceph module is loaded
• Validate existing snapshots against external checksums and recreate any snapshots taken on vulnerable kernels if integrity is required

Patch Information

The fix has been merged across multiple stable trees. Reference commits include Linux Kernel Commit 36673344, Linux Kernel Commit 4097e70f, Linux Kernel Commit 531a76c5, Linux Kernel Commit 5788b742, Linux Kernel Commit 69e59a87, Linux Kernel Commit 757873ab, Linux Kernel Commit 9efa1546, and Linux Kernel Commit f16bd3fa. Confirm with your distribution vendor that backports are present in the kernel package you deploy.

Workarounds

• Avoid hole-punching operations (fallocate -p, FALLOC_FL_PUNCH_HOLE) on CephFS files that participate in snapshots until kernels are patched
• Restrict CephFS client capabilities so untrusted users cannot issue punch-hole operations against snapshotted datasets
• Use the userspace Ceph client (ceph-fuse) on hosts where the kernel client cannot be updated promptly, after confirming the userspace client is unaffected

# Verify the running kernel includes the ceph_zero_partial_object() snapshot-context fix
uname -r

# Identify CephFS mounts on the host
mount -t ceph

# Inventory client kernel versions across a fleet (example using SSH)
for host in $(cat cephfs_clients.txt); do
  ssh "$host" 'echo $(hostname): $(uname -r)'
done