CVE-2026-43273

What it actually does

This Linux kernel CephFS client flaw causes ceph_zero_partial_object() to issue Ceph OSD write operations without the correct snapshot context. When partial object zeroing or hole-punching operations occur after a CephFS snapshot is created, the operation can affect snapshot-visible data incorrectly, resulting in snapshot data inconsistency. Exploitation is local and requires a user or process with access to a mounted CephFS filesystem and permission to modify files; no remote network-only exploitation is indicated by the CVSS vector.

Why it matters to the business

Organizations using CephFS snapshots for backup, recovery, rollback, compliance retention, or forensic preservation could find that snapshots do not reliably preserve file contents. The practical risk is failed recovery, corrupted historical data, loss of trust in snapshot-based backup workflows, and operational disruption during restore or incident response. The issue is not currently listed in CISA KEV, has very low EPSS, and has no reported exploit maturity, but it affects a core kernel filesystem path and should be prioritized where CephFS snapshots protect critical data.

How an attack unfolds

An attacker or untrusted local user first obtains access to a system that has CephFS mounted through an affected Linux kernel client. They create or identify a file covered by a CephFS snapshot, then perform a partial zeroing or hole-punching operation against the live file, such as using fallocate with punch-hole behavior. Because the kernel client omits the appropriate snapshot context during the Ceph OSD write, the operation can cause the snapshot view of the file to diverge from its expected preserved content. The attacker can repeat this against important files to undermine snapshot reliability or cause operational denial of service when recovery depends on those snapshots.

How to fix it

Upgrade affected Linux kernel packages to a version that includes the upstream CephFS fix for supplying snapshot context in ceph_zero_partial_object(). Because no exact fixed versions were provided, use the fixed kernel versions published by the relevant Linux distribution or kernel vendor for CVE-2026-43273, and prioritize hosts that mount CephFS with snapshot usage. If immediate patching is not possible, reduce exposure by limiting local shell access to CephFS clients, restricting write permissions on CephFS paths covered by critical snapshots, limiting use of hole-punching/sparse-file operations by untrusted workloads, and ensuring important CephFS data is also protected by independent backups outside the affected snapshot path.

How to confirm the fix worked

Confirm the running kernel on CephFS client systems is updated to a vendor build containing the CephFS ceph_zero_partial_object() snapshot-context fix. Validate operationally by creating a test CephFS file, taking a snapshot, performing a partial zeroing or hole-punching operation on the live file, dropping client caches or remounting, and confirming the snapshot copy retains the original checksum. Review package changelogs or vendor advisories for the specific CVE or the patch title 'ceph: supply snapshot context in ceph_zero_partial_object()'.

Typical attack path

1. Gain local access to a host using an affected Linux kernel with a mounted CephFS filesystem.
2. Obtain write permission to files or directories that are protected by CephFS snapshots.
3. Create, wait for, or identify an existing CephFS snapshot containing target files.
4. Perform partial zeroing, hole punching, or similar sparse-file modification operations against the live file.
5. Trigger cache eviction or later reads so the inconsistent snapshot contents become observable.
6. Use the corrupted or unreliable snapshot state to disrupt recovery, rollback, or integrity assumptions.

How to detect it

There are no unique network indicators for this vulnerability because exploitation is local and uses legitimate filesystem operations. To assess possible prior exploitation, review Linux audit logs, EDR telemetry, shell histories, and process accounting for unusual use of fallocate, hole-punching, truncate, or sparse-file modification tools against CephFS mount points, especially shortly after snapshots were created. Review Ceph MDS and OSD logs for unusual write or zeroing activity around affected files and snapshot timelines, though the vulnerable operation may not produce a distinctive error. Perform forensic validation by comparing checksums of critical files in CephFS snapshots against independent backups, application-level records, or known-good copies. Give special attention to snapshots created while affected kernels were running and later accessed after partial zeroing or hole-punching occurred on the live file.

What your security team should do

• Inventory Linux systems that mount CephFS, especially those using CephFS snapshots for backup, retention, rollback, or recovery.
• Patch CephFS client kernels to vendor-fixed versions as soon as available, prioritizing systems with untrusted local users or multi-tenant workloads.
• Restrict write access to snapshot-protected CephFS paths until patched, and review whether untrusted workloads can issue fallocate, hole-punching, or sparse-file modification operations.
• Run integrity checks on critical CephFS snapshots created or used while affected kernels were in service, comparing snapshot contents against independent backups where possible.
• Ensure critical data protected by CephFS snapshots also has independent backup coverage until all clients are remediated and snapshot integrity is verified.
• Monitor for unusual local use of file hole-punching or partial-zeroing operations on CephFS-mounted paths.
• Because this is not in CISA KEV, has low EPSS, and has no known public exploit maturity, treat it as a targeted reliability and data-protection risk rather than an active mass-exploitation emergency.