ceph: reject exporttargets ranks >= CEPHMAXMDS in mdsmap decode

Ceph is an open-source distributed storage platform providing object, block, and file storage. In versions prior to 20.2.4 and 19.2.6, the Monitor subscription handler fails to properly authorize access to the configuration-key store, allowing any CephX user with only  mon allow r capabilities to read the entire store by sending a single crafted MMonSubscribe message. The config-key store holds sensitive secrets including OSD LUKS disk-encryption passphrases and, on cephadm-managed clusters, the SSH private key that cephadm uses to reach every host in the cluster. Because that key grants root on every node under the default cephadm configuration, a low-privileged read-only account can escalate to full cluster and host compromise. This issue is fixed in versions 20.2.4 and 19.2.6

A flaw was found in the ceph-ansible playbook where it contained hardcoded passwords that were being used as default passwords while deploying Ceph services. Any authenticated attacker can abuse this flaw to brute-force Ceph deployments, and gain administrator access to Ceph clusters via the Ceph dashboard to initiate read, write, and delete Ceph clusters and also modify Ceph cluster configurations. Versions before ceph-ansible 6.0.0alpha1 are affected.

A vulnerability was discovered within Ceph. An attacker can exploit our prior use of hardcoded IVECs, in a misuse of AES, similar to PERILS in Kerberos4, resulting in authentication bypass.

Ceph is an open-source distributed storage platform providing object, block, and file storage. In versions prior to 20.2.4 and 19.2.6, the CephX authentication protocol encrypts tickets with AES-128-CBC in an unauthenticated mode that uses a hard-coded initialization vector and no message authentication, allowing an attacker to forge credentials and gain cluster-wide access. Because the ciphertext is malleable and the monitor will encrypt attacker-chosen entity names, an attacker holding one low-privilege key and able to observe CephX traffic can use the monitor as an encryption oracle and splice ciphertext blocks into valid tickets for privileged entities such as Manager, MDS, and OSD. The same lack of authentication also lets an attacker with CephX permissions escalate privileges by flipping a single bit in a service ticket to set its allowall field to true. This issue is fixed in versions 20.2.4 and 19.2.6.

Ceph is an open-source distributed storage platform providing object, block, and file storage. In versions prior to 20.2.4 and 19.2.6, the CephX authentication protocol encrypts tickets with AES-128-CBC in an unauthenticated mode that uses a hard-coded initialization vector and no message authentication, allowing an attacker to forge credentials and gain cluster-wide access. Because the ciphertext is malleable and the monitor will encrypt attacker-chosen entity names, an attacker holding one low-privilege key and able to observe CephX traffic can use the monitor as an encryption oracle and splice ciphertext blocks into valid tickets for privileged entities such as Manager, MDS, and OSD. The same lack of authentication also lets an attacker with CephX permissions escalate privileges by flipping a single bit in a service ticket to set its allowall field to true. This issue is fixed in versions 20.2.4 and 19.2.6.

Ceph is an open-source distributed storage platform providing object, block, and file storage. In versions prior to 20.2.4 and 19.2.6, the RADOS Gateway (RGW) protects STS session tokens with an AES-128-CBC handler that provides no message authentication, allowing an attacker who holds any valid STS token to tamper with it undetected and escalate to full RGW administrative access. Because the ciphertext is unauthenticated, the attacker can perform a CBC bit-flip on the accttype, permtype, and isadmin fields of their own token, and a forged isadmin value triggers a global administrative override that bypasses all capability checks. The attack is reachable remotely over the RGW S3 endpoint and is a self-contained modification of a token the attacker already possesses, requiring no encryption oracle and no network observation. It requires only a single valid STS token, which need not carry any elevated privileges, with STS enabled. This issue is fixed in versions 20.2.4 and 19.2.6.

Ceph is an open-source distributed storage platform providing object, block, and file storage. In versions prior to 20.2.4 and 19.2.6, the Ceph Object Gateway (RGW) SigV4 handler does not reject requests that carry x-amz- headers absent from the signed header set, allowing anyone holding a presigned URL to attach arbitrary unsigned x-amz- headers that RGW will honor. AWS S3 requires every x-amz- header on a SigV4 request to be signed and rejects requests bearing additional unsigned headers, but RGW validates only the headers listed in X-Amz-SignedHeaders and ignores any extra ones, so they take effect without being covered by the signature. By adding such headers to a presigned PUT URL, an attacker can grant themselves more capabilities than the URL's signer intended and escalate their privileges. This issue is fixed in versions 20.2.4 and 19.2.6.

A flaw was found in the way ceph mon handles user requests. Any authenticated ceph user having read access to ceph can delete, and corrupt snapshot images.

This would require user to have read access and for that user must have key for authentication. It would only affect snapshots and images. So attacker with read access will only be able to corrupt data of snapshot images and rest of the ceph cluster should work as it is. Affect on integrity would be low and availability part can be controlled by mitigation using 'monallowpooldelete = false' in ceph.conf to disable deletion of pools

Ceph is a distributed object, block, and file storage platform. In versions up to and including 19.2.3, using the argument x-amz-copy-source to put an object and specifying an empty string as its content leads to the RGW daemon crashing, resulting in a DoS attack. As of time of publication, no known patched versions exist.

ceph: cap delegated inode count in cephparsedeleginos()

In the Linux kernel, the following vulnerability has been resolved:

libceph: validate OSD extent maps before cursor advance

net/ceph/osdclient.c:osdsparseread() validates that the sparse-read data length matches the summed extent lengths, but it does not validate that each OSD-supplied extent is monotonic and lies inside the original request range. A malformed authenticated OSD reply can advertise a far-forward nonzero extent offset with a matching data length and make the client advance the message-data cursor beyond the request buffer. This reaches the BUGON(!length) assertion in cephmsgdatanext() from the client receive path.

Impact: A malicious or compromised authenticated Ceph OSD peer can crash a kernel Ceph client via a malformed sparse-read reply.

Reject sparse extent maps that overflow, move backwards, overlap, or extend outside the original sparse-read request before advancing the cursor.

[ idryomov: perform sparseextentmapvalid() check a bit earlier, in CEPHSPARSEREADDATALEN instead of CEPHSPARSEREADDATAPRE state ]

Ceph is a distributed object, block, and file storage platform. In versions up to and including 19.2.3, using the argument x-amz-copy-source to put an object and specifying an empty string as its content leads to the RGW daemon crashing, resulting in a DoS attack. As of time of publication, no known patched versions exist.

Ceph is a distributed object, block, and file storage platform. In versions up to and including 19.2.3, using the argument x-amz-copy-source to put an object and specifying an empty string as its content leads to the RGW daemon crashing, resulting in a DoS attack. As of time of publication, no known patched versions exist.

A flaw was found in the Ceph RGW configuration with Beast as the front end handling client requests. An unauthenticated attacker could crash the Ceph RGW server by sending valid HTTP headers and terminating the connection, resulting in a remote denial of service for Ceph RGW clients.

A flaw was found in rados gateway shipped as part of ceph. Unclosed file descriptors while denying TCP connections to SSL serving port pile up until exhaustion of resources leading to potencial remote denial of service.

This vulnerability affects the RadosGW OIDC provider by allowing attackers to bypass authentication using JWTs with "none" as the algorithm (alg). The lack of signature enforcement creates a serious risk of unauthorized access and privilege escalation.

The vulnerability is probably in the RadosGW OIDC provider.

PoC

The HTTP request can be found below. But without the JWT:

POST / HTTP/2 Host: storage.xxx.se User-Agent: aws-sdk-go-v2/1.18.0 os/macos lang/go/1.21.1 X:nocoverageredesign md/GOOS/darwin md/GOARCH/arm64 api/sts/1.19.0 Content-Type: application/x-www-form-urlencoded Amz-Sdk-Invocation-Id: 30a74697-7d7e-4c02-b041-97d68156ee78 Amz-Sdk-Request: attempt=1; max=3 Content-Length: 1508 Accept-Encoding: gzip, deflate, br

Action=AssumeRoleWithWebIdentity&DurationSeconds=3600&RoleArn=arn%3Aaws%3Aiam%3A%3Aorgpentest002%3Arole%2Fu-pentest002STS&RoleSessionName=test&Version=2011-06-15&WebIdentityToken=ey..

A vulnerability was discovered within Ceph. An attacker can exploit our prior use of hardcoded IVECs, in a misuse of AES, similar to PERILS in Kerberos4, resulting in authentication bypass.

Use of a broken cryptographic algorithm vulnerability in Ceph RGW's STS session token handling. The STS tokens use the same unauthenticated AES-128-CBC handler as CephX (CVE-2025-30156) and share its lack of integrity protection. An attacker holding any valid STS token can use CBC bit-flipping to modify the token contents without detection, obtaining full RGW admin access. Unlike the CephX attack which requires access to the internal cluster network and a Ceph monitor, this attack is a self-contained modification of a token the attacker already holds, requiring only a single valid unprivileged STS token and STS to be enabled.

Improper verification of cryptographic signature vulnerability in Ceph RGW's SigV4 handler. The flaw is caused by RGW only verifying the validity of headers listed in X-Amz-SignedHeaders without checking whether additional unsigned x-amz- headers are present on the request. AWS S3 requires every x-amz- header to be signed and rejects requests carrying unsigned headers, but RGW does not enforce this check. An attacker holding only a presigned PUT URL can attach arbitrary x-amz- headers that RGW applies, granting more capabilities than the original signer intended, resulting in privilege escalation.

Missing authorization vulnerability in the MON subscription handler of Ceph distributed storage. The flaw allows any CephX user with mon allow r capabilities to read the entire MON config-key store by sending a single crafted MMonSubscribe message. This exposes OSD LUKS passphrases and, on cephadm-managed clusters, the SSH private key that cephadm uses to access every host, yielding root access under the default cephadm configuration. The attacker must have access to the Ceph cluster network and a compromised account with mon allow r permissions. No user interaction is required.

In ceph, HTTP request headers without a ":" character that are handled in rgwcivetweb.cc:RGW::initenv() can cause variables to be set to NULL, leading to a crash or other potentially unspecified behaviour.

Upstream Pull Request:

https://github.com/ceph/ceph/pull/20403

A flaw was found in rados gateway shipped as part of ceph. Unclosed file descriptors while denying TCP connections to SSL serving port pile up until exhaustion of resources leading to potencial remote denial of service.

ceph: do not repeat cephtrimdentries() if no progress possible

A non-privileged user can change the permissions from a directory owned by the root user an can gain access to the targeted directory.

A flaw was found in the way signature calculation is handled by cephx protocol. The signature calculation is encrypting a 29 byte struct with 16-byte block AES cipher, and then using the first 8 bytes of the result as signature. This only covers first (16 by tes) cipher block, datacrc falls on second block.There are no known exploits against this, If attacker can alter the message payload any changes in datacrc will not be noticed or checked by signature check.

A flaw was found in the way the Ceph RGW Beast front-end handles unexpected disconnects. An authenticated attacker can abuse this flaw by making multiple disconnect attempts resulting in a permanent leak of a socket connection by radosgw. This flaw could lead to a denial of service condition by pile up of CLOSEWAIT sockets, eventually leading to the exhaustion of available resources, preventing legitimate users from connecting to the system.

A resource-permission flaw was found in the tripleo-heat-templates package where ceph.client.openstack.keyring is created as world-readable. A local attacker with access to the key could read or modify data on Ceph cluster pools for OpenStack as though the attacker were the OpenStack service, thus potentially reading or modifying data in an OpenStack Block Storage volume. This has been patched in versions 7.0.6 and 8.0.0.

In the Linux kernel, the following vulnerability has been resolved:

ceph: fix possible deadlock when holding Fwb to get inlinedata

1, mount with wsync. 2, create a file with ORDWR, and the request was sent to mds.0:

cephatomicopen()--> cephmdscdorequest(openc) finishopen(file, dentry, cephopen)--> cephopen()--> cephinitfile()--> cephinitfileinfo()--> cephuninlinedata()--> { ... if (inlineversion == 1 || / initial version, no data / inlineversion == CEPHINLINENONE) goto outunlock; ... }

The inlineversion will be 1, which is the initial version for the new create file. And here the ci->iinlineversion will keep with 1, it's buggy.

3, buffer write to the file immediately:

cephwriteiter()--> cephgetcaps(file, need=Fw, want=Fb, ...); genericperformwrite()--> aops->writebegin()--> cephwritebegin()--> netfswritebegin()--> netfsbeginread()--> netfsrreqsubmitslice()--> netfsreadfromserver()--> rreq->netfsops->issueread()--> cephnetfsissueread()--> { ... if (ci->iinlineversion != CEPHINLINENONE && cephnetfsissueopinline(subreq)) return; ... } cephputcaprefs(ci, Fwb);

The cephnetfsissueopinline() will send a getattr(Fsr) request to mds.1.

4, then the mds.1 will request the rd lock for CInode::filelock from the auth mds.0, the mds.0 will do the CInode::filelock state transation from excl --> sync, but it need to revoke the Fxwb caps back from the clients.

While the kernel client has aleady held the Fwb caps and waiting for the getattr(Fsr).

It's deadlock!

URL: https://tracker.ceph.com/issues/55377

In the Linux kernel, the following vulnerability has been resolved:

ceph: fix memory leak in cephmdsauthmatch()

We now free the temporary target path substring allocation on every possible branch, instead of omitting the default branch. In some cases, a memory leak occured, which could rapidly crash the system (depending on how many file accesses were attempted).

This was detected in production because it caused a continuous memory growth, eventually triggering kernel OOM and completely hard-locking the kernel.

Relevant kmemleak stacktrace:

unreferenced object 0xffff888131e69900 (size 128): comm "git", pid 66104, jiffies 4295435999 hex dump (first 32 bytes): 76 6f 6c 75 6d 65 73 2f 63 6f 6e 74 61 69 6e 65 volumes/containe 72 73 2f 67 69 74 65 61 2f 67 69 74 65 61 2f 67 rs/gitea/gitea/g backtrace (crc 2f3bb450): [<ffffffffaa68fb49>] kmallocnoprof+0x359/0x510 [<ffffffffc32bf1df>] cephmdscheckaccess+0x5bf/0x14e0 [ceph] [<ffffffffc3235722>] cephopen+0x312/0xd80 [ceph] [<ffffffffaa7dd786>] dodentryopen+0x456/0x1120 [<ffffffffaa7e3729>] vfsopen+0x79/0x360 [<ffffffffaa832875>] pathopenat+0x1de5/0x4390 [<ffffffffaa834fcc>] dofilpopen+0x19c/0x3c0 [<ffffffffaa7e44a1>] dosysopenat2+0x141/0x180 [<ffffffffaa7e4945>] x64sysopen+0xe5/0x1a0 [<ffffffffac2cc2f7>] dosyscall64+0xb7/0x210 [<ffffffffac400130>] entrySYSCALL64afterhwframe+0x77/0x7f

It can be triggered by mouting a subdirectory of a CephFS filesystem, and then trying to access files on this subdirectory with an auth token using a path-scoped capability:

$ ceph auth get client.services [client.services] key = REDACTED caps mds = "allow rw fsname=cephfs path=/volumes/" caps mon = "allow r fsname=cephfs" caps osd = "allow rw tag cephfs data=cephfs"

$ cat /proc/self/mounts services@[REDACTED].cephfs=/volumes/containers /ceph/containers ceph rw,noatime,name=services,secret=<hidden>,msmode=prefer-crc,mounttimeout=300,acl,monaddr=[REDACTED]:3300,recoversession=clean 0 0

$ seq 1 1000000 | xargs -P32 --replace={} touch /ceph/containers/file-{} && \ seq 1 1000000 | xargs -P32 --replace={} cat /ceph/containers/file-{}

[ idryomov: combine if statements, rename rc to pathmatched and make it a bool, formatting ]