Mitigating the CephX Authentication Bypass (CVE-2025-30156) on RLC Pro LTS 9.6 and FIPS 9.6, Including the FIPS Mode Restriction

cve cve-2025-30156 cve-2026-43304 security kernel ceph storage fips rocky linux lts mitigation troubleshooting

Arian Cabrera
Sr. Customer Support Engineer

Oct 27, 2026

FIPS mode restriction: on these kernels the Ceph kernel client can't use aes256k keys when FIPS mode is enabled. FIPS mode clients must keep using a legacy aes key, and the Ceph cluster must be configured to accept it. See FIPS mode restriction before rotating keys on any FIPS mode system.

Introduction

CVE-2025-30156 (CVSS 3.1: 8.9, High) is a weakness in CephX, the authentication protocol used by Ceph storage clusters. CephX encrypts tickets with AES-128-CBC using a fixed initialization vector and no message authentication. An attacker who holds any valid low-privilege CephX key and can reach the cluster network can use the Ceph monitor as an encryption oracle, then splice the resulting ciphertext into forged credentials for privileged entities such as OSDs, MDSs and managers. A second path flips a single bit in a service ticket to grant full access. Either path can give the attacker cluster-wide read, write and administrative access.

The upstream Ceph project fixed the issue in Squid 19.2.6 and Tentacle 20.2.4. The fix adds a new CephX key type, aes256k, based on the Kerberos 5 encryption type AES256-CTS-HMAC-SHA384-192 (RFC 8009). Existing keys use the legacy aes type and remain vulnerable until they are rotated to aes256k.

Systems that mount CephFS or map RBD images with the Ceph kernel client (the ceph and libceph kernel modules) need a kernel that understands aes256k keys before their keys can be rotated. CIQ has backported this support to the RLC Pro LTS 9.6 and RLC Pro FIPS 9.6 kernels. The same kernel also fixes CVE-2026-43304, a missing key length check in libceph, along with three fixes to the kernel's Kerberos 5 crypto library that the aes256k support depends on (CVE-2026-31719, CVE-2026-64439 and CVE-2026-80924).

Problem

CVE-2025-30156 is a flaw in the Ceph protocol, so the primary fix is on the Ceph cluster. The kernel update matters for systems that act as Ceph kernel clients. Without it, those clients can only authenticate with legacy aes keys, which keeps the cluster from retiring the vulnerable key type.

Treat the following as affected if they use the Ceph kernel client to mount CephFS or map RBD images:

RLC Pro LTS 9.6
RLC Pro FIPS 9.6

Exploitation requires a valid CephX key, even a low-privilege one, and network access to the Ceph cluster. It can't be exploited by a user who has no CephX credential.

Systems that don't use the Ceph kernel client aren't exposed through the kernel. Userspace clients such as ceph-fuse and rbd-nbd don't use the Ceph kernel client, and get aes256k support from the Ceph client packages instead.

Status

The patched kernel is pending release. The RLC Pro LTS 9.6 and RLC Pro FIPS 9.6 kernel is in the release process. The Patched Kernels table lists its version, and this article will be updated with the release date when it ships.
The Ceph cluster needs its own update. Upgrade the Ceph cluster to Squid 19.2.6, Tentacle 20.2.4 or later, then rotate keys to aes256k as described in the upstream Ceph documentation. The kernel update alone doesn't stop a client from using the old mechanism. A client keeps using a legacy aes key until its key is replaced.
FIPS mode systems keep legacy keys. The FIPS-certified cryptographic module in these kernels doesn't include the algorithms behind aes256k, so Ceph kernel clients in FIPS mode can't use the new key type. See FIPS mode restriction.
Recommended action: Install the patched kernel on non-FIPS Ceph kernel clients and reboot, upgrade the Ceph cluster, then rotate the keys of those clients to aes256k. For FIPS mode clients, keep their existing aes keys and limit which systems hold them.
Rocky Linux community releases: CIQ does not publish patched kernels for community Rocky Linux editions. For community release patching status, refer to Rocky Linux Errata.
Open a support case if you need help confirming which of your systems use the Ceph kernel client, or planning the key rotation.

FIPS mode restriction

When FIPS mode is enabled, the kernel only allows algorithms covered by its FIPS certificate. The Kerberos 5 encryption type that aes256k keys use isn't covered by the certificate for these kernels, and adding it would require the kernel to be certified again. CIQ chose to ship the security fixes without changing the certified algorithm list.

As a result, on a FIPS mode system running the patched kernel:

The Ceph kernel client can't instantiate the aes256k cipher, so a mount or map that uses an aes256k key fails.
The Ceph kernel client continues to work with a legacy aes key.
The key type is part of the key itself, passed on the mount command line with secret= or read from the file named by secretfile=. There is no separate mount option that selects the key type.

To keep FIPS mode clients working, the Ceph cluster administrator must:

Keep aes in the cluster's allowed cipher list, so the monitors still accept legacy keys.
Leave the keys of FIPS mode clients as aes. Don't rotate them to aes256k.

Legacy aes keys remain vulnerable to CVE-2025-30156. A cluster that accepts them stays exposed to an attacker who holds one. The Ceph monitors report this with the AUTH_INSECURE_KEYS_ALLOWED and AUTH_INSECURE_CLIENT_KEY_TYPE health warnings, which will stay raised while FIPS mode clients use legacy keys. To reduce exposure, give each FIPS mode client its own CephX entity with the narrowest capabilities it needs, and restrict network access to the cluster to the systems that need it.

Check whether a system is in FIPS mode:

cat /proc/sys/crypto/fips_enabled

A value of 1 means FIPS mode is enabled and the restriction applies.

Patched Kernels

Variant	Patched Kernel Version	Repo	Released
RLC Pro LTS 9.6	`kernel-5.14.0-570.60.1+27.1.el9_6_ciq`	rlc-9.6-lts.x86_64	Pending
RLC Pro FIPS 9.6	`kernel-5.14.0-570.60.1+27.1.el9_6_ciq`	fips-9.6-compliant-x86_64	Pending

The Repo links require your CIQ depot credentials. If you need to retrieve them, log in to the CIQ Portal.

CIQ updates this table as tested kernels become available for each variant.

Installing the Update

Once the patched kernel is available, refresh the DNF metadata, update and reboot:

sudo dnf clean all && sudo dnf makecache
sudo dnf update kernel*
sudo reboot

If the update does not appear, confirm that the depot channel for your product is enabled:

sudo depot enable lts-9.6      # RLC Pro LTS 9.6

Rotating Ceph kernel client keys

Run these steps on the Ceph cluster after it has been upgraded to Squid 19.2.6, Tentacle 20.2.4 or later. The upstream Upgrading and Rotating CephX Keys guide covers the full procedure, including daemon keys. The steps below cover only the Ceph kernel clients.

Allow both key types during the migration

List the cipher types the monitors currently accept:

ceph --format=json mon dump | jq -r '.auth_allowed_ciphers | map(.name) | join(",")'

Allow both the legacy and the new key type:

ceph mon set auth_allowed_ciphers aes,aes256k

Non-FIPS clients

After the client is running the patched kernel, rotate its key to aes256k. Replace $ID with the client's CephX name:

ceph auth rotate --key-type=aes256k client.$ID | tee ./client.$ID.keyring

Copy the new key to the client, replacing the old keyring or secret file, then remount CephFS or remap the RBD images that use it.

FIPS mode clients

Don't rotate the keys of FIPS mode clients. Leave aes in auth_allowed_ciphers for as long as any FIPS mode client connects to the cluster. Removing it with ceph mon set auth_allowed_ciphers aes256k locks those clients out.

Verification

Confirm the running kernel on each Ceph kernel client:

uname -r

The output should match the patched version in the Patched Kernels table, or be newer.

Confirm whether the system is in FIPS mode, which decides which key type the client can use:

cat /proc/sys/crypto/fips_enabled

On the Ceph cluster, list the clients that still use legacy keys:

ceph health detail

The AUTH_INSECURE_CLIENT_KEY_TYPE warning lists the client entities that still have aes keys. Once rotation is done, only FIPS mode clients should remain in that list.

Resolution

Install the patched kernel on every RLC Pro LTS 9.6 and FIPS 9.6 system that uses the Ceph kernel client, and reboot.
Upgrade the Ceph cluster to Squid 19.2.6, Tentacle 20.2.4 or later.
Rotate the keys of non-FIPS Ceph kernel clients to aes256k.
Keep legacy aes keys only for FIPS mode clients, and leave aes allowed on the cluster while they remain.
If no FIPS mode clients use the cluster, remove aes from auth_allowed_ciphers after every key has been rotated, as described in the upstream Ceph guide.

Notes

Installing the patched kernel doesn't change which key a client uses. A client that still holds an aes key keeps authenticating with the vulnerable mechanism until its key is replaced, whether or not FIPS mode is enabled.
The FIPS restriction applies to the Ceph kernel client only. It doesn't affect other uses of the kernel in FIPS mode.
The RLC Pro FIPS 10.2 kernel, currently going through FIPS certification, includes the aes256k algorithms in its FIPS-allowed set, and they are part of the certification review. This article will be updated when that certification completes.
CVE-2026-43304 and the Kerberos 5 crypto library fixes are included in the same kernel and apply in both modes. They exist to support the Ceph kernel client, so they have no practical effect on systems that don't use it.
ceph-fuse and rbd-nbd don't use the Ceph kernel client, so the restriction in this article doesn't apply to them.