CVE-2025-40362

What it actually does

The MDS auth caps check omits fsname validation, causing capabilities granted for one Ceph filesystem to be incorrectly applied to a different filesystem in a multi-FS cluster.

Why it matters to the business

Users authorized for read-only access on one filesystem can perform unauthorized read/write operations on another, risking data integrity and confidentiality in multi-tenant Ceph deployments; affected OpenShift nodes require urgent updates given the published remediation deadline.

How an attack unfolds

An attacker creates multiple Ceph filesystems, grants a single client differing permissions per filesystem via ceph fs authorize, updates the keyring, mounts the restricted filesystem, and performs write operations that succeed because the caps from the other filesystem are incorrectly reused.

How to fix it

Upgrade containernetworking-plugins and related debug packages on Red Hat OpenShift 4.3 (el7/el8) to 0:0.8.6-1.rhaos4.3.el7 or 0:0.8.6-1.rhaos4.3.el8; apply Linux kernel commit 07640d34a781bb2e39020a39137073c03c4aa932 or later stable releases that enforce fsname validation in ceph_mount_options.

How to confirm the fix worked

Confirm package versions match the listed fixed releases, review Ceph MDS and client logs for absence of "fsname mismatch" warnings, and test that a client authorized only for read access on one filesystem can no longer write to another.

Typical attack path

1. Create two or more Ceph filesystems in the same cluster
2. Authorize the same client with different MDS caps on each filesystem
3. Update and distribute the client's keyring
4. Mount a filesystem where the client should have only read access
5. Execute write or delete operations that incorrectly succeed due to cross-filesystem cap leakage

How to detect it

Search Ceph client and MDS logs for "fsname mismatch" messages, unexpected successful touch/rm operations on read-only mounts, and keyring updates followed by cross-filesystem permission bypass indicators.

• fsname mismatch
• fsname check failed
• client.usr mount with differing caps across filesystems
• touch succeeding on read-only Ceph mount

What your security team should do

• Apply the fixed package versions immediately on all affected OpenShift nodes using multi-FS Ceph
• Audit Ceph authorization configurations to ensure fsname-specific caps are correctly scoped
• Monitor for unexpected write activity from clients with read-only grants until patches are deployed