From: Sasha Levin <sashal@kernel.org>
To: xmei5@asu.edu, co+ecaada42f806f629@bugs.sh, amarkuze@redhat.com,
idryomov@gmail.com
Cc: stable@vger.kernel.org
Subject: FAILED: patch "[PATCH] ceph: fix integer overflow in the snap trace bounds check" failed to apply to 5.10-stable tree
Date: Sat, 7 Nov 2026 06:29:06 -0500 [thread overview]
Message-ID: <20261107062906-failed-5.10-b3bf89767e3c@kernel.org> (raw)
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y
git checkout FETCH_HEAD
git cherry-pick -x b3bf89767e3ca9506f1c7167cac97c41ec254d42
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '20261107062906-failed-5.10-b3bf89767e3c@kernel.org' --subject-prefix 'PATCH 5.10.y' 'HEAD^..'
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From b3bf89767e3ca9506f1c7167cac97c41ec254d42 Mon Sep 17 00:00:00 2001
From: Xiang Mei <xmei5@asu.edu>
Date: Tue, 15 Sep 2026 14:40:27 -0700
Subject: [PATCH] ceph: fix integer overflow in the snap trace bounds check
ceph_update_snap_trace() bounds the two encoded snapid arrays that follow a
struct ceph_mds_snap_realm with sizeof(u64) * (num_snaps +
num_prior_parent_snaps). Both counts come straight off the wire as __le32,
so the addition is evaluated in unsigned int and wraps before sizeof(u64)
promotes it to size_t: an MDS sending num_snaps = 1 and
num_prior_parent_snaps = 0xffffffff makes the sum zero and the check
degenerates to ceph_decode_need(&p, e, 0, bad), which always passes.
dup_array() then reads num_snaps * 8 bytes past the end of the message
front, which ceph_msg_new2() allocates at exactly front_len bytes. An
unsolicited CEPH_MSG_CLIENT_SNAP reaches this from a malicious or
compromised MDS with no client-side action, as do the snaptraces carried in
an MDS reply and in a cap import.
Compute the length with size_add()/size_mul() so it saturates at SIZE_MAX
instead of wrapping, in the style fs/ceph/mdsmap.c already uses for
num_export_targets.
BUG: KASAN: slab-out-of-bounds in dup_array (include/linux/unaligned.h:28 fs/ceph/snap.c:500)
Read of size 8 at addr ffff8880102a16c8 by task kworker/1:2/129
Workqueue: ceph-msgr ceph_con_workfn
Call Trace:
dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
kasan_report (mm/kasan/report.c:595)
dup_array (include/linux/unaligned.h:28 fs/ceph/snap.c:500)
ceph_update_snap_trace (fs/ceph/snap.c:836)
ceph_handle_snap (fs/ceph/snap.c:1155)
mds_dispatch (fs/ceph/mds_client.c:7234)
ceph_con_process_message (net/ceph/messenger.c:1424)
ceph_con_v1_try_read (net/ceph/messenger_v1.c:1430)
ceph_con_workfn (net/ceph/messenger.c:1576)
process_one_work (kernel/workqueue.c:3396)
worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
...
The buggy address is located 0 bytes to the right of
allocated 72-byte region [ffff8880102a1680, ffff8880102a16c8)
Cc: stable@vger.kernel.org
Fixes: 963b61eb041e ("ceph: snapshot management")
Reported-by: co+ecaada42f806f629@bugs.sh
Assisted-by: LLM
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
---
fs/ceph/snap.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/ceph/snap.c b/fs/ceph/snap.c
index 498ffc1a91cb8..5c1540d95b8c3 100644
--- a/fs/ceph/snap.c
+++ b/fs/ceph/snap.c
@@ -788,6 +788,7 @@ int ceph_update_snap_trace(struct ceph_mds_client *mdsc,
struct ceph_snap_realm *first_realm = NULL;
struct ceph_snap_realm *realm_to_rebuild = NULL;
struct ceph_client *client = mdsc->fsc->client;
+ size_t snaps_len;
int rebuild_snapcs;
int err = -ENOMEM;
int ret;
@@ -802,8 +803,10 @@ int ceph_update_snap_trace(struct ceph_mds_client *mdsc,
ceph_decode_need(&p, e, sizeof(*ri), bad);
ri = p;
p += sizeof(*ri);
- ceph_decode_need(&p, e, sizeof(u64)*(le32_to_cpu(ri->num_snaps) +
- le32_to_cpu(ri->num_prior_parent_snaps)), bad);
+ snaps_len = size_mul(size_add(le32_to_cpu(ri->num_snaps),
+ le32_to_cpu(ri->num_prior_parent_snaps)),
+ sizeof(u64));
+ ceph_decode_need(&p, e, snaps_len, bad);
snaps = p;
p += sizeof(u64) * le32_to_cpu(ri->num_snaps);
prior_parent_snaps = p;
--
2.53.0
next reply other threads:[~2026-11-07 11:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 11:29 Sasha Levin [this message]
2026-11-10 23:09 ` [PATCH 5.10.y] ceph: fix integer overflow in the snap trace bounds check Sasha Levin
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=20261107062906-failed-5.10-b3bf89767e3c@kernel.org \
--to=sashal@kernel.org \
--cc=amarkuze@redhat.com \
--cc=co+ecaada42f806f629@bugs.sh \
--cc=idryomov@gmail.com \
--cc=stable@vger.kernel.org \
--cc=xmei5@asu.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.