From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (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 5483A2690EC for ; Sat, 6 Jun 2026 19:00:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780772450; cv=none; b=mLO8pU8iQRrFbiAC2BjY2WfePPZcDdiOPKjfTys7N0VPky4sgcUlQ48mHQiQUD3aIxqXuIPWYK3odoXWt6eEBz87nDnnoDfQldOOSokr0/HmPxSBbh6ZAeM0c145iNLz/X8eoRCSIs4Sj7yEXLDqw81+JiROa/Ng9pIGrbSqd9g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780772450; c=relaxed/simple; bh=p04gKZewWGHGeiIshvk8TxG729gV4NtSvKoh07Wi73I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cyiTP3Bxztza2GHbR29opHp5ucWuqfyICFOPtePOtoW8gQhCj3WzsjCY2HTOhF+7TK8+qCZXzrUiiHii8vGtmP+41YIpP3tr5szQSzz/aR5u+xRNT8RODE6TYsDL68k2hZca3RRFGJbQNs99+g4t8GQjM3HbkOmMpDGObFkOqn8= 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=fA6rHTda; arc=none smtp.client-ip=209.85.160.174 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="fA6rHTda" Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-5176bbb9384so31493991cf.1 for ; Sat, 06 Jun 2026 12:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780772448; x=1781377248; 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=bXuQS8LAd9fbsQ2k1v5BJHiia9ttbolctoKgd5+Hdl4=; b=fA6rHTdaGXFrUDO4W2Yv0Ev98NBIx9HtlBVOknljIjf8TL3lr61Q7wA4qOGnnjfe/9 Uy7GLG2gikcSPg3UjrVS4baQaP+BUxn6fkBtRfxJQTWoc6Bvt8x7tKxduHxvWtD1OiBW 42cjUh9AyeTQRQP3g2vYvWzBKrcRP4LJV6uIMtQrTBBwVT0cvZZcwjfM8xBpQR+U91BQ mhj1NNTLhRYZ5oH2F3XgNMCn8fNqCM9AycWD63XgimCs6NU/y1U1fVnxhZP2lpGvF/+p Hlmexc3auVbXdwVBM8i3nqQzUvU0QZXaysIGTNuJSXYLj6oYWJ+5h+RPYK/4uq3D2pnE yMCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780772448; x=1781377248; 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=bXuQS8LAd9fbsQ2k1v5BJHiia9ttbolctoKgd5+Hdl4=; b=mCTjoVhhduWCU/ZcT5JP4ZC/Gwa1BVezhS5IjrTJlCDkA8ZpQdvDxGfU8Obh7ixd67 q423WUkrmz8FMyuX8MKSXrOU4yL+v4AEFP156CKN4Ng+azVsvv+un7D1bdQtLDcuf3mY KbWopbM7FHxXXcnFjUIc1qdc+QtXo/KNvLxo9H8yqlhkgYNWTrG0l0cIudVhUhWS0wH9 8tfCPGmclEkD4s4L2pSLFm+PTO6zpZpzls1FKlINFYB3X/XfYYUQD1PrzHeWM2blXBVA PyDLOXSqYmuU5VhyRXN17mhUccejo04r+/EJA+xmy97AQ9KhzCGfqUan2qvRqwPsF67i 6wUw== X-Forwarded-Encrypted: i=1; AFNElJ+i7YFydhsy3EEVChlsd+26OX+9LaUEq13AvE3zyrO7FEkK+czh21En9/VVHwHmw4qugD75juUdnVx+sEc=@vger.kernel.org X-Gm-Message-State: AOJu0YzsowHq7u/wbBYynC6BMhmMKd5wTVkQRE9eyCw0SDUGwbU/GSMz aoyz5HFeEhkCPpQwAj9WPEbKnKZ3XBPraXyvXDuaHKeMccS5H4XsjcNjfsIaOwWZAGI= X-Gm-Gg: Acq92OGHHLz78CsqFGXhrmZ92y/8AFANtHVhd61n5h6L5eeHbte9ZI82rFnxMEKQVv7 wv4jvpu0gMAYfMas/ZkyEse4Xwze5F2qZCj/5c4lfrtmDopEUvBv+gJkKV8UfW19vn1/JyTRP6b pi+rnrMix7qteAZO8R3JAZQRTA/0CADHf+xSW66/eA3UthqRYbdivKsoH5cBcR8mfQe2g2zZEVu ApQ5uwEaQtDtu824DVOxGn06vJAETEFnSNX+5PT6BdToFnSLdnfR5C0dzrn8nDuDNjdFylWukc5 AI+xiq5ILQbaDzah04q/h0HxYhRNaGTMN4mToerdtiqh4PuripjlsBCGQD110pY7CjGc8m5O1kE 5ZpjWzNG5XY272mB1C5qJPT9AOVe56yx2TKBUdXm2zjwTsIkjoDDHYDb/zpEPLnOVmkT8xFcoXX x+CpSRA/O4ZqVq8Flproz5vYh0vyk1ak4+Hfw4NYkufLzhPmn6A3eRu2VkyCjoklMYPSKGNMcQC uIMMSQLpJYXoaYU60h3w4gJFuC5ORA= X-Received: by 2002:a05:622a:1451:b0:516:e031:933f with SMTP id d75a77b69052e-51795b0e76cmr128614291cf.6.1780772446093; Sat, 06 Jun 2026 12:00:46 -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-5179dd9d908sm40084581cf.15.2026.06.06.12.00.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2026 12:00:44 -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 v2 1/4] ceph: bound xattr value length in __build_xattrs() Date: Sat, 6 Jun 2026 15:00:22 -0400 Message-ID: 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 Reviewed-by: Viacheslav Dubeyko --- v2: - Add Reviewed-by from Viacheslav Dubeyko. 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