From: Michael Bommarito <michael.bommarito@gmail.com>
To: Ilya Dryomov <idryomov@gmail.com>,
Alex Markuze <amarkuze@redhat.com>,
Viacheslav Dubeyko <slava@dubeyko.com>
Cc: ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/4] ceph: bound untrusted MDS and monitor reply decoders
Date: Thu, 4 Jun 2026 14:08:56 -0400 [thread overview]
Message-ID: <cover.1780596023.git.michael.bommarito@gmail.com> (raw)
The CephFS client decodes several variable-length fields from MDS and
monitor replies without checking the declared length against the bytes
actually present in the message. Each of the four sites below trusts a
32-bit or 64-bit length from the wire and then copies, advances over, or
loops on it. A malicious or compromised server (or, for the monitor map,
an on-path attacker on an unsigned messenger session) can drive an
out-of-bounds read or an unbounded loop in the client kernel. The fixes
add the missing ceph_decode_need()/ceph_decode_copy_safe() bound or an
explicit count cap, matching the idioms already used elsewhere in the
same decoders.
Patch 1 is the most serious: the over-read value is returned to user
space through getxattr(2), so it is a kernel-heap information leak
(AC:H, requires a user to read the attribute). Patches 2-4 are
out-of-bounds reads / an unbounded loop that crash or wedge the client
(denial of service, no information disclosure). For patch 3 the supplier
is the monitor, a more privileged cluster role than the MDS; it is
included as a hardening fix for the info_v 2/3 compatibility path.
All four were reproduced on x86_64 QEMU with CONFIG_KASAN=y by calling
the real decoder via an in-tree debugfs harness, and re-run with the
patch applied:
patch 1: stock - __build_xattrs() stores val_len=304 from a 256-byte
blob, then the getxattr memcpy is a slab-out-of-bounds read of
304 bytes; patched - decode returns -EIO, no value stored.
patch 2: stock - slab-out-of-bounds read of 512 bytes in
handle_session(); patched - the bound rejects the record.
patch 3: stock - slab-out-of-bounds read in ceph_mdsmap_decode();
patched - decode returns -EINVAL.
patch 4: stock - ceph_parse_deleg_inos() runs 1048640 iterations on a
crafted len; patched - returns -EIO before the loop.
Well-formed replies still decode in every case (valid xattr value,
in-range delegation, in-bounds export-target array). These bugs were
found with AI assistance and are reported on the public list
accordingly, especially since they are mostly about a malicious
trusted server.
Michael Bommarito (4):
ceph: bound xattr value length in __build_xattrs()
ceph: bound MDSCapAuth path and fs_name decode in handle_session()
ceph: bound num_export_targets array for mds info v2/v3
ceph: cap delegated inode count in ceph_parse_deleg_inos()
fs/ceph/mds_client.c | 22 ++++++++++++++++++++--
fs/ceph/mdsmap.c | 2 ++
fs/ceph/super.h | 9 +++++++++
fs/ceph/xattr.c | 1 +
4 files changed, 32 insertions(+), 2 deletions(-)
base-commit: f72c95f3a516d87483e225ae081a402a09fd0127
--
2.53.0
next reply other threads:[~2026-06-04 18:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-04 18:08 Michael Bommarito [this message]
2026-06-04 18:08 ` [PATCH 1/4] ceph: bound xattr value length in __build_xattrs() Michael Bommarito
2026-06-04 19:50 ` Viacheslav Dubeyko
2026-06-04 18:08 ` [PATCH 2/4] ceph: bound MDSCapAuth path and fs_name decode in handle_session() Michael Bommarito
2026-06-04 19:54 ` Viacheslav Dubeyko
2026-06-04 18:08 ` [PATCH 3/4] ceph: bound num_export_targets array for mds info v2/v3 Michael Bommarito
2026-06-04 20:04 ` Viacheslav Dubeyko
2026-06-04 20:23 ` Michael Bommarito
2026-06-04 18:09 ` [PATCH 4/4] ceph: cap delegated inode count in ceph_parse_deleg_inos() Michael Bommarito
2026-06-04 21:06 ` Viacheslav Dubeyko
2026-06-04 21:41 ` Michael Bommarito
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1780596023.git.michael.bommarito@gmail.com \
--to=michael.bommarito@gmail.com \
--cc=amarkuze@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=slava@dubeyko.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox