From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793831140; b=Fg48dmGlG1ylwNZtmOeTT4iAy1wU18IUa9v/lftSFi5qBkSrRcZRnEua+OXzf1N5Y/Yp 8g+LH30txWtCKGVVUmMXix4p3H8HEe8tsMOMWWgTRSYcajcay1GTUKh4lJhUyyykOCs9U NfVsIU1pNXqHfS8qkT1BXSS8uD9/DMacYRcKeWi7PDhHyjGZTsMpGG26aUlfeYktOh6lf vXcCnJnBJWFR/Lb2AdZeT2DGbH17UOcUAYCnBknsXiFrWW3Y3GyPu1/DpqBxIkIQEiD4n dOdeIQu1na117Pj8SsIxxo+dl5L36+TCLaMnnAztKTXJXpKdyaJ6PFJRIXlD0m5Ke1w== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793831140; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=OWHWtNnipRgLtmDplSZCmnZ6XY5bpGEIH29pdklLruI=; b=AS3TIM+xkso3XcSnMhypRsjwc45ddFICP36zTWMpNV0zKyeczAIrv+eekjForBdMWS27 Mz6bAlJnw9fsB32G7H8uRuYIYGHlECGg31z9x3v8VtFC/oewDtjjuQP0CLepZ04M/Jvu9 8FnWiotjzdUQ95c+f3kLMKAVNwHx6hCpgZvTueDcxgQhLERAPnOojUoQieeCdTTCJI21/ 9JwoB+roM2ScYfyJ+/DkNQaeBsbgCV9wmxMekttcs3OdDcgJnvpshJ6XbY7s9Rh1eJCa3 zxSS4jTA31i78kAkcU/Li3i2HyPBsZtmIZ75XJs1lns4v4aVcgukCT+Jg3LV4JzC0qA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=SfCcaQHt; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A2CF0606B3B8; Wed, 4 Nov 2026 22:25:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=SfCcaQHt Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F6031F000C1; Wed, 4 Nov 2026 22:25:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793831139; bh=OWHWtNnipRgLtmDplSZCmnZ6XY5bpGEIH29pdklLruI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=SfCcaQHt8/9G2dAwUJcBm3N1Wu2JIJugyBjfAERQzIbCL8e6DBSNNfn5eHqJ2kBrK yjO6M7MLRzXrMuXnJ7wMAuEVcRzXUMMpakHXnmxowb8y7cX4KR8LBw0Ufy/5zhUpb1 ad4Uow1j9ok3RUFAz0/bBfii98GSyW5DGngMB7zI= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, co+25860fb17af97289@bugs.sh, Xiang Mei , Alex Markuze , Ilya Dryomov Subject: [PATCH 6.18 0522/1005] libceph: bound mon_command ack decode to front len Date: Wed, 4 Nov 2026 16:04:15 -0500 Message-ID: <20261104211058.541352121@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261104211043.516122098@linuxfoundation.org> References: <20261104211043.516122098@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Xiang Mei commit 62b41a16d8603d4d809fda212f15c3e9c783a82b upstream. handle_command_ack() bounds the decode with msg->front_alloc_len, the size of the reply buffer, instead of msg->front.iov_len, the number of bytes the monitor sent. mon_alloc_msg() routes every CEPH_MSG_MON_COMMAND_ACK to get_generic_reply(), which returns the preallocated ->reply of whichever generic request carries the same tid, so the buffer keeps its fixed size however short the reply is. An ack with hdr.front_len below sizeof(struct ceph_mon_request_header) + sizeof(u32), including 0, still passes ceph_decode_need(), and ceph_decode_32() returns four bytes that were never received: uninitialized slab memory, stale bytes of an earlier message, or bytes the peer planted by sending a reply that lands in the same buffer and is then rejected. The read stays within the allocation, so KASAN does not flag it. req->result reaches userspace through ceph_monc_do_statfs(), ceph_monc_get_version() and ceph_monc_blocklist_add(); rbd hands it back from write() on /sys/bus/rbd/add_single_major, and rbd_get_client() passes it to ERR_PTR() unchecked, which faults: rbd: failed to get latest osdmap: -186318427 BUG: unable to handle page fault for address: fffffbfffe9ca034 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:do_rbd_add (drivers/block/rbd.c:7105) Call Trace: ... kernfs_fop_write_iter (fs/kernfs/file.c:345) vfs_write (fs/read_write.c:595 fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception Use msg->front.iov_len, matching handle_subscribe_ack(), handle_statfs_reply(), handle_get_version_reply() and handle_auth_reply(). A well-formed ack has front.iov_len >= 22 and is unaffected; a short one takes the existing bad: path. This applies commit d3c32939fa0e ("libceph: bound get_version reply decode to front len") to the last decode-side use of front_alloc_len in this file. Cc: stable@vger.kernel.org Fixes: 6305a3b41515 ("libceph: support for blacklisting clients") Reported-by: co+25860fb17af97289@bugs.sh Assisted-by: Cursor Signed-off-by: Xiang Mei Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman --- net/ceph/mon_client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/ceph/mon_client.c +++ b/net/ceph/mon_client.c @@ -943,7 +943,7 @@ static void handle_command_ack(struct ce { struct ceph_mon_generic_request *req; void *p = msg->front.iov_base; - void *const end = p + msg->front_alloc_len; + void *const end = p + msg->front.iov_len; u64 tid = le64_to_cpu(msg->hdr.tid); dout("%s msg %p tid %llu\n", __func__, msg, tid);