From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 91E283A75B1 for ; Thu, 4 Jun 2026 18:09:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780596553; cv=none; b=KEY+VweMXOawP63g0jZsz5y4E1OYACng5/uTB06vc9wbm9t+EDurhU4PvUBXi4UZe4Cxjr2kMv/JHl7iBqxkhhScDPQz6KjGL2LDT86BO/0FVprou8EJ7CI8oSWlg7v1tDOTUvx0T6e4QwxY8T+LpOuC44U1jvu0DNxFrzjBLp8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780596553; c=relaxed/simple; bh=bT58V/InFAWfeakk78BgVqBWmxLwpXGinvWy6zPUJf8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CCRe/qzKNOXTBknNePGfWT3709voU9ps6nFnABa0F9olVYSPmMRXs8lqiNYWr79VKIgKsmmps+RnKak38GG7HK0Nie/68SwqlPGyv1GUxW3ufbUUm9zu+XB9X6zxhnAch/lRSHs2yAGsLvYqLj2pS58tONuvvaoIQDA4HSs6+xM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=A6xGcdsg; arc=none smtp.client-ip=209.85.160.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="A6xGcdsg" Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-51784eb2ba0so7921491cf.2 for ; Thu, 04 Jun 2026 11:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780596550; x=1781201350; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ZRBmb4WQIMwOp8EJqjAWjm9PjUUHk3D5HPtS2dDVrls=; b=A6xGcdsgzCcGOqoAjMfEDfRTvQBBJszQ0GM3jVbP65DDzfkevXrSXQQ3kkSw7HAgv0 YtQ5D/PrRRC3g2Ixs1KilJEjSsPp6IdJ+x2z7wCXBbxOUja+bADxqUWuVxLH6F9wOpBR FItw3wtmV/SkpH/9WNiPS5DwGTK3p57U7Zg1qcDYlCyj/tpS0BkJjxoWDLt06VgiDAAB 92p8Bh9in89XJLKOTA3kphDY3uMtSyHL0fEnxobfcxZIsTIJvlNo4L6PeGdrvpjXtGPb 2qhSs82QHHkGV56M/J47MW/6Q2iZlA9jvSRaBqtdJAK/LOx3irjkm8EoqOS+5fEyD8zV 7+hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780596550; x=1781201350; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ZRBmb4WQIMwOp8EJqjAWjm9PjUUHk3D5HPtS2dDVrls=; b=kLehUNbb+tynZwjxPiIqFO8Uv5fIin1ojn/oJDyVeGPQTwJ4LCrUXcNKvwOxROTFPR iuPmhWP/NKZDsbzk41+MonoyfUwrowIMuI8r5YHwoQYb5qDQsJ7WM/tbFGR0mCv22rbW xim7Vg84jAcPRJsPZcVKTz1dL0mhWmVxLIpYQnQH7oereGEDlofVvtLZh7TtJsbTrO8x vPF3S4QhEMm566xjv8ygTO/A9iwBasbo0LFCsZCVsJ/q6u81lFaYfQIW4YzbqXOG/hR/ qEt3OKfdLRBEp986+fOrOkRtgKj8Mbo8zlgKruoL6uw7c2yr8h1Lzp0gXj+cLVSdf9hD UJ9g== X-Forwarded-Encrypted: i=1; AFNElJ9MvgGuTxR4rAekUOQpxEHF6x5tp/ZAmKnHRsXBrCsHPcu2OgYihhNB+lNz35Q+lqlK2b9sfY+PMWOtVTQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwYeuHMItuMWVZ5oWWqv7qfEd547J06CWZjHcthgWGQ997LBfHp U5aedl3LkQ/Ih8cs5DuVvmDgLT+uViqdSrsEmxxAbpoucN6GHXxpUEgY X-Gm-Gg: Acq92OE32WqIkGugo7v1znoT3d6wChwnXsCZA3qU7KP7M38QvMYFWR7lbZVWkGgAiES SSDcN4oRsGUrnYbLQSO2SCfmI6Tor2NEN+77MCmr2N/y3x0zNjl16zdwEAkKJAhZmp9Ky18zzks lU+xQVWo7AL17DmPoymrT0lbeenkSDgpImoUhK8PnDBj9iZf6HvVODklN4L9Tp8JWArpEwFl8KQ I0rekbV4po6iUIKrei5ZQfMre9JpSMT2wbAuVhRucTt7HU3lDpJ/UKMHhm+7yh51CdvNzelKhBW oPU+h1eaB0KNL/swdeMqfyp2HF10EkArq8Q14oWvj2SNJTwaeVE3tjw8XYkgQVC59rFQaVW5Qmt FG7iU8E5201mwppbSgU6pcZ3AHGO1bLuYmAFhxXXzZBaQ9Dj2aWcHV6TWywwxsM5cseHCLvb43Z gOKp4MUWZC4h2lEkPF0L0MwWdGFT/OHxIJ3FFrB+hvpGZeWvTyL66jZqemQ493zANmtPUsS8zVP JC0X+vdJ64Lu9s7+G7uxHwjDVzWWI1JWRsbXb/xGA== X-Received: by 2002:a05:622a:a98e:20b0:517:8fb6:56ba with SMTP id d75a77b69052e-5178fb659a0mr25295821cf.24.1780596550612; Thu, 04 Jun 2026 11:09:10 -0700 (PDT) Received: from server0 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-51775dbd2c9sm59020961cf.23.2026.06.04.11.09.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jun 2026 11:09:09 -0700 (PDT) From: Michael Bommarito To: Ilya Dryomov , Alex Markuze , Viacheslav Dubeyko Cc: ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/4] ceph: bound xattr value length in __build_xattrs() Date: Thu, 4 Jun 2026 14:08:57 -0400 Message-ID: <97a34ff3743172b1278f211d47a500a07eb25732.1780596023.git.michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare "p += len" and no ceph_decode_need() check that "len" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored. Fixes: 355da1eb7a1f ("ceph: inode operations") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-8 --- fs/ceph/xattr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ceph/xattr.c b/fs/ceph/xattr.c index e773be07f7674..d488bb8fc00ba 100644 --- a/fs/ceph/xattr.c +++ b/fs/ceph/xattr.c @@ -848,6 +848,7 @@ static int __build_xattrs(struct inode *inode) name = p; p += len; ceph_decode_32_safe(&p, end, len, bad); + ceph_decode_need(&p, end, len, bad); val = p; p += len; -- 2.53.0