From nobody Mon Jun 8 05:24:51 2026 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: quoted-printable Content-Type: text/plain; charset="utf-8" __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 +=3D 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 =3D p; p +=3D len; ceph_decode_32_safe(&p, end, len, bad); + ceph_decode_need(&p, end, len, bad); val =3D p; p +=3D len; =20 --=20 2.53.0 From nobody Mon Jun 8 05:24:51 2026 Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) (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 C9D173BB4A for ; Sat, 6 Jun 2026 19:00:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780772453; cv=none; b=lR3lRXHXSib21o5W985YSr282xTT5LOf1R1HSQLR7FXYZPeIk2C+Sqv1GWyeAWrkjihf4dnEiqSsWxy+hjJ+2+3iYEE0MKu0dSOswyI/CjsB2eQc4mOMFztyxCHuPQS7kgTFBZDPcDtc9ixTv6NIvQEYct/bXu9FMbm85UG72/M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780772453; c=relaxed/simple; bh=G/p1NhEroBtnSctFQHymP/5qrkJPeSykOHnFiiTppw8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Zen4XI2DIhBSq/tZaLeFweAa/U2Ikwz8QgzRW+A6fJMMdz/r0WpBiLg0KPTLLHqawQ8QKMDL3endBE2FJ9n9TWAf+f6SlTu7lcgLHvHQlcNf4Hg6/0/AHJGehdic15mfS3ZjW1ER7FutCuNB9vw1os6oHXkKMZm+5JA8ltn/1Os= 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=dc942fNb; arc=none smtp.client-ip=209.85.219.44 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="dc942fNb" Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-8ccdf8d4ac5so33957906d6.1 for ; Sat, 06 Jun 2026 12:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780772451; x=1781377251; 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=LaXCfO1Mwv1k6w0bpsL9U/18c9DbefbI9xxe01qkWag=; b=dc942fNbfiwz5uya30TH7a0o+tvcE7h1eHvwTOCoqH0X2h4BUEI7pTt3iYFeGC6xVK tmJHLXEXQ/8QTaunP0KI27I0A7WW43EoLgWMBCbKAbWwBrwBm2aPwv9tfDuVsbB1xXQq ukG/lB+S2sCCTiD/HCWUeaV7E/EBUqzjdPtmpffH2uwRrtLQFLBdUNJikE70+g4jhhTm YezlLO82GRahax3uGKXiVxPAloaurYLm1Qk9nKb8OEGIIvEwJPCF43jtmTNpZDg6K4/r TIMSzPAXvfDme9Jv0xBa6dHTUsAFDENtInRx/uIR6Sd+NNGPlu8NhEyjAZv1TNGpb3G1 jvmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780772451; x=1781377251; 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=LaXCfO1Mwv1k6w0bpsL9U/18c9DbefbI9xxe01qkWag=; b=YM9cn7dlMuqDMQAy5vYqMAKd9A/Inhx8Gs7mgtV/Nspk6wjB2fm0ZP0VHY7NTTC4F9 ySUAss+4peaXy1jnAIsrR18ossWo0AyZA8pKbGv/aKJWl6UeIvZPpe3lm+iNq+maCuZH sM1Xe+1rSt8J7Z3qlKBaVwu9swu1IrGDb2dyI4Id+YeTfGVPLfsd+rIUxM3kuTHI45nY 6N9URvXwSzP8uPLTl7OzwcqjM1qu/3ILYnlRTCvvzZTaQZrtok7kV2zks56ve7o/1GDc FxuxFCOOwyBSOQ24ywUZX6CJB7HgVX7wuRkxZhJUSJS0P+mccwZcF1QCRdcKs+DiqvYS nPtg== X-Forwarded-Encrypted: i=1; AFNElJ+kOEMEX5hGB86tW/uVlaKKxmLbGJGiilocAVPk/5drT3/BRnDWgEo7gRXldyVaYQM4H1m6TKkeUFDIEzo=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1BqfEOCyiFmXfS5DrOHliRHZZ9AhMEE+QQHhgm5F2q9iFcJGU 9JWSRDY4VlOeqMpBV2/GuVgJ3s/j6G7Ch5InZAErFlSWd6Dqt8ICAUi9 X-Gm-Gg: Acq92OFkToZowiB9P79TxklzGfewiAONs3uFfsFSBcYM3rVULhaIaHSc+ofNYFVNDgx /PkH1XTAEBL7hKJ4LK+VYryYgr5+TcoIia6FYG8hk/3KXZtio8lWZl6g7qjs/g+K58k14BFwG/c lgVRh2S+YRZAFir5iHpVGtenPfHEoxf0g+1wJ+D7NBBDGYIM4jD8iUoPtPHM1X3eZtBS7fahje8 8VYtKwtlWzvwCqFHOj5HRGb40lkwFRJ28i70jtqacftny2nD52FyE6UK2CeIdXzcYh7sbLTDk1p sKIif5mRMDTjyFa0FgWW23SFKG45NpfBzhuSVKybVH1vn9ajr70TZu/t7OkthJFu6BJmRkI9mWm BHM0Gszq9CDo4qJbJfZjFik7nIym+Vpo+wyGIbQVW2OM1BWHuOXqAdaQTGs3aarXbmqcj0fGsPG J+olMFumaedoaDd/rBSGlqyohn3P60Zr6g2+FIhlyo/D5rfvN/ecK8aINOjgNbBvT3xpARFZpTl aP24+bcei6QbgQ9m6XXCc96BSHkjRI= X-Received: by 2002:a05:622a:411:b0:517:6351:b401 with SMTP id d75a77b69052e-51795c0763fmr137402321cf.44.1780772447684; Sat, 06 Jun 2026 12:00:47 -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.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2026 12:00:46 -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 2/4] ceph: bound MDSCapAuth path and fs_name decode in handle_session() Date: Sat, 6 Jun 2026 15:00:23 -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: quoted-printable Content-Type: text/plain; charset="utf-8" handle_session() decodes the MDSCapAuth records carried by a CEPH_SESSION_OPEN message (msg_version >=3D 6). For each record the match.path and match.fs_name byte strings are read by first decoding a 32-bit length and then copying that many bytes with the bare ceph_decode_copy(). Unlike the surrounding fields, which all use the _safe decode variants, these two copies are not preceded by a ceph_decode_need() bounds check, and the enclosing MDSCapAuth and MDSCapMatch struct_len fields are skipped rather than enforced as an upper bound. A length larger than the bytes remaining in the message front makes ceph_decode_copy() read past the end of the front buffer. The message front is a dedicated allocation (ceph_msg_new2() -> kvmalloc), so the over-read runs off that object. A malicious or compromised MDS can trigger this with the first post-connect message on mount, with no client-side user interaction; under KASAN it is reported as a slab-out-of-bounds read in handle_session(). Impact: a malicious MDS can force the kernel client to read up to 4 GiB past the message front allocation during session setup, crashing the client (out-of-bounds read). Switch both copies to ceph_decode_copy_safe(), which performs the ceph_decode_need() bounds check before the copy and branches to the existing bad label, matching the rest of the decoder and the error path that frees the partially decoded cap_auths array. Fixes: 1d17de9534cb ("ceph: save cap_auths in MDS client when session is op= ened") 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/mds_client.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c index ed17e0023705e..4f36ac73305dc 100644 --- a/fs/ceph/mds_client.c +++ b/fs/ceph/mds_client.c @@ -4318,7 +4318,9 @@ static void handle_session(struct ceph_mds_session *s= ession, pr_err_client(cl, "No memory for path\n"); goto fail; } - ceph_decode_copy(&p, cap_auths[i].match.path, _len); + ceph_decode_copy_safe(&p, end, + cap_auths[i].match.path, + _len, bad); =20 /* Remove the tailing '/' */ while (_len && cap_auths[i].match.path[_len - 1] =3D=3D '/') { @@ -4335,7 +4337,9 @@ static void handle_session(struct ceph_mds_session *s= ession, pr_err_client(cl, "No memory for fs_name\n"); goto fail; } - ceph_decode_copy(&p, cap_auths[i].match.fs_name, _len); + ceph_decode_copy_safe(&p, end, + cap_auths[i].match.fs_name, + _len, bad); } =20 ceph_decode_8_safe(&p, end, cap_auths[i].match.root_squash, bad); --=20 2.53.0 From nobody Mon Jun 8 05:24:51 2026 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (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 831652F0680 for ; Sat, 6 Jun 2026 19:01:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.178 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780772464; cv=none; b=Hmuanz5uCaoSeEHYPqKE+1rLZk5aSBKamK7O2BifjM7EuvJglIrb0H+yIc5PmljqhY+yIQY5GKMDP9VfwlwOxF0Yfbif2cGpsMtOVHAxYeAOyTMZz2rYDbBxMH3Ql5rgtXqYKOpraRxxemu1tBd8YS8MAzNMFK7qAOQTYhGAktg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780772464; c=relaxed/simple; bh=BW2BrX08wC02nhzpIAaJjo2SaZf8rRBP097fOQ4cghg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=c6SdO7OdxxQPINIsXwkdK96ip18BAnJO+t/y1oacOvC0/ZFbgXgbQBInuDywtsAdJ5eV1hdDwfgVH2lYLgAhUB07udKVbXZbrwexWME0J5QWi2T9AT+4O7CR5AhcOprMDFQLDHgMzUqsnL4dIAyAKkQa7aSTOhvza1zpU+YNQNw= 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=OogKPP/J; arc=none smtp.client-ip=209.85.160.178 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="OogKPP/J" Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-5176096116fso32904041cf.0 for ; Sat, 06 Jun 2026 12:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780772460; x=1781377260; 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=DlGP8cAl6M3KGH4/UHsP3eZyZ7kf3DnixlYL4kMyqao=; b=OogKPP/J7QOu2R4KoneW2nPmTaLHMjJMgIxX+U5NZxAf7cukwgbFO1B2/X+G5qBoFh 5agYWlB/9KW1wR5PWahlbcNL8Tvo5WuylzdK5ET/2IJs02HiOzKT770B3nVR/dr6qPJi 4RI6sbvMaGABp+53jyCVX/XqHoOzOuv2kToUtgu7T4ShXapfrwL+LSquYEXWXwhMiqOH ysyXXTsLlp04pS3JJ8+QjnYGW697Vr4i63j2Oy07p6px07SRKnmzEVsOcflrAuunMbOo EsdLqI25Q0VI9yyfPJmvgvwWOplq3cjxsExCyXSbkCLL6oZ98U2hzy9+p2sVoeWJ7KwA FaMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780772460; x=1781377260; 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=DlGP8cAl6M3KGH4/UHsP3eZyZ7kf3DnixlYL4kMyqao=; b=K6neqYgAy4hbSYSJ5/huNwSEqHCQ6hNEFYZmSeVdpKLsUpxHX0FH4IIHMwt6s9Dotu n4NK0Wyjvtq4Sc8DCh6Z5KJy5K1k26rPSLCEnqrxXiEa73regoqIThVfOxEg35rF4EiR fcHLLiXy+dGgiV3zvHU8PDJ57YTnv95+fR4RMJBwqrs8/CpD4mJCQ9+dLRFdPEVAUQM+ OvF8Xu5LQ8dNPbjd2HDTVzmam/lxkg/lF+4w64YiWdvMi5GR+7jpw2aLtjSxV4MtQc9i oMx+mALDpxXiPmQcIluraG8tAFfEOpBaTmV7dDQslQmivNfY4tj9nqjzxwBY7DCxSB53 NlQw== X-Forwarded-Encrypted: i=1; AFNElJ//VSA6odYGlnPLLuM317a9TC3I/nlIufbqYoF3adbEm7v/sg0cVDvcX6MiVGLOAHeUkkyeXYmcwrTuRsI=@vger.kernel.org X-Gm-Message-State: AOJu0Yzh/gkdep//CL7tS/fE0g8FPeybvVZLAMd24ZIdWwDlYgP+cAGd LWhRN4HAxTNsLMxazA4BAXMMHaHoPVpQo+UsTEbUt6ktm+ebM97EwCOD X-Gm-Gg: Acq92OF0HRV6Q/Bs2FCVoeo9eKPBwFuiR6sql9Op2w1IYG7negjCGUYpQIXVn8VJVRZ nEbeEaQfpqBqsHXch5SzdxFjxs2+0BO98+vtozW5KQ6OvmQTKP3BWLX7OMHuO78UTAfj+jRL1zA 6MOveuh8Et8bPc+UIRwl+SPsA6fJJjJi4RIDrLxXQFboI2aYE1xBt3ZheQe7DCS0htVSmHTJT7N 4DPapFCsG+qA2KVuNzDXHG29SnHS6ZIeVAx6feU5GWrDmZ8zEqIUouitHWHHgrtqQ3koak2b/ua YY/syMc+/ISxdr2Btzy7NY2PmQQGctE1RLFnI65g1UDhlwWmywBQkQo69uFSYMwQb3bYwuP4S5U A6ekc3l4pq+xMooyeZ8gca39KPwPXWRh7ylrm6A7x+z2uNEpZzDCNd5UjuD+yGchmXuCL/dn9Yn L6kbn+KtKVfs6ZUoJF2cXefAbwloNmO5UX8GVjWlJP2IwktEYDQq3nb4wk036gt9a59GCnnESOc R4XaSVh+tghjZbWA54/DPL5sZWUct4= X-Received: by 2002:a05:622a:1481:b0:517:6378:e671 with SMTP id d75a77b69052e-51795c640d5mr128065961cf.55.1780772448978; Sat, 06 Jun 2026 12:00:48 -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.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2026 12:00:48 -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 3/4] ceph: bound num_export_targets array for mds info v2/v3 Date: Sat, 6 Jun 2026 15:00:24 -0400 Message-ID: <9d77173c026185448a9a7fc9b22c18f0a915d161.1780766417.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: quoted-printable Content-Type: text/plain; charset="utf-8" ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from each per-mds info record and advances the decode cursor by num_export_targets * sizeof(u32) without first checking that many bytes remain. The only upper-bound check that catches a runaway cursor (*p > info_end) is gated on info_v >=3D 4, because info_end is left NULL for info_v 2 and 3. When the monitor sends an MDS map whose per-mds info version is 2 or 3 with an oversized num_export_targets, the cursor moves past the message front buffer and the later export-targets loop calls the unchecked ceph_decode_32() on out-of-bounds memory. A kernel client processes CEPH_MSG_MDS_MAP from its monitor session (net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an on-path attacker on an unsigned/unencrypted messenger session, can therefore drive an out-of-bounds read in the client kernel; on x86_64 with KASAN it is reported as a slab-out-of-bounds read in ceph_mdsmap_decode(). The decoded values land in the internal info->export_targets[] array, so the consequence is a kernel out-of-bounds read, not an information leak to the attacker. Impact: a malicious or compromised Ceph monitor sending an MDS map with a per-mds info version of 2 or 3 and an oversized num_export_targets field triggers an out-of-bounds read in the CephFS client kernel. Add a ceph_decode_need() for the export-targets array before advancing the cursor, so the bound is enforced for every info_v >=3D 2, not only info_v >=3D 4. This mirrors the count-then-need idiom already used for m_data_pg_pools later in the same function. Compute the export-targets byte count with size_mul() and reuse that checked length when advancing the cursor, so the attacker-controlled num_export_targets multiplication fails closed on overflow rather than relying on the later kcalloc() guard. Fixes: d463a43d69f4 ("ceph: CEPH_FEATURE_MDSENC support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito --- v2: - Compute the export-targets byte count with size_mul() and reuse the checked length when advancing the cursor. fs/ceph/mdsmap.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/ceph/mdsmap.c b/fs/ceph/mdsmap.c index d8e46eb7e5eb5..c0f63f0460f67 100644 --- a/fs/ceph/mdsmap.c +++ b/fs/ceph/mdsmap.c @@ -3,6 +3,7 @@ =20 #include #include +#include #include #include #include @@ -126,6 +127,7 @@ struct ceph_mdsmap *ceph_mdsmap_decode(struct ceph_mds_= client *mdsc, void **p, u8 mdsmap_v; u16 mdsmap_ev; u32 target; + size_t export_targets_len; =20 m =3D kzalloc_obj(*m, GFP_NOFS); if (!m) @@ -224,8 +226,11 @@ struct ceph_mdsmap *ceph_mdsmap_decode(struct ceph_mds= _client *mdsc, void **p, *p +=3D namelen; if (info_v >=3D 2) { ceph_decode_32_safe(p, end, num_export_targets, bad); + export_targets_len =3D size_mul(num_export_targets, + sizeof(u32)); + ceph_decode_need(p, end, export_targets_len, bad); pexport_targets =3D *p; - *p +=3D num_export_targets * sizeof(u32); + *p +=3D export_targets_len; } else { num_export_targets =3D 0; } --=20 2.53.0 From nobody Mon Jun 8 05:24:51 2026 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (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 A4197309EE6 for ; Sat, 6 Jun 2026 19:00:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780772453; cv=none; b=iHLnZp52NuUdWPCqSEVoy6dyQbGNz1bpSUifnYyvUaQfcvVfAB9zVFlC6hDjQgZsjqa4jNKyM3caE4tv9clFZpS6xZ0P8msd/+6xp4yrjsuerxdB/3VLFZ0tjfsI7T/wlSlcGfRCle/gRpxqvbBn4EZvRmW12Z+t29K+F8vuhZM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780772453; c=relaxed/simple; bh=4sMY40AkLnXatMC0Anyvm+jDAzp0G51q8wrYyo7vcHc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ccb1OxAOgRQ24BkebuVemlrqtFNlCKFbz63AiUeeGsl/lGDPuQ7UwSyAYweibDg+6nEmsAhhrKuOwSIJy1WscbJ7kq8dpxlGEYWf7Khen3ZfuDkX3IlRbiqRYvb3ERgz6spI894zlofhvVRnPl230JrvscM2Q351mXPkaiV+FGM= 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=qp9PmiSN; arc=none smtp.client-ip=209.85.160.182 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="qp9PmiSN" Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-5174a1d78f8so27318191cf.2 for ; Sat, 06 Jun 2026 12:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780772450; x=1781377250; 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=2DjmgW1mXPm4joNioJYRGWEnxoZsgWtSa55pt1fPZlM=; b=qp9PmiSN33E8ymQU1zszyol5vcLqz/Stn8ztrEFenT5B+0p8P+XaG3twMdestXTvrN YinhRVNfz65+z+Itrx5273x8uO51F5BCHTOADDTf7VE0QAtwpIG1tGaDsMCa97NQw4LJ 6+gcj1BoPu8SrJln0Hp8ejGiRMoZS79xvL0aHp4pij0QcSqPiWybCkRlg4nt1mxHl1fr f0cMzI6Vu+czQ/Ro/U9vJJiqC6fxme/b9b2rBBcLdVrPq6LoodOzyzdLeUGiUjq/6Xi3 LjrzxhinGUjlViSvMoYTg5TRg/01E+t+LlmzOualF4da+6z5Dq+33QtMXB5rmfvYgHPD TK9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780772450; x=1781377250; 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=2DjmgW1mXPm4joNioJYRGWEnxoZsgWtSa55pt1fPZlM=; b=NlXencpqnYPgyECEqf1VOED0Hvx3WnEIrJNmj+ZAhWmtbs1vr2jJKyD5EPF8ltO/rF U+HFBmsa449lW3255hOHrz49uNB65OUOC57iZa9tU6FQcmgQp1vX75e6lsdaMIZMcwN0 ndNXQg6WetwepZtNoqmo3wJAdB0Qd3MGLlWsUW0PTKXnHMxdePOj9LKgUezE9lrnaQOo ziQWgfThsipyl7HxMvcJSejJhIOhI/bEiL7awpmrMQuIfS7OmQ49VKLKPZUZP0qU0knA N3Elaps96/jTJQnFus8mds88NzLfaLk/opWQk+Wu/8/b38HlNHDPgcgRUHplGjVqB7Ux Oy4Q== X-Forwarded-Encrypted: i=1; AFNElJ+t+/SqQ5mgHU7zBotOL6w7zuZnOzZ6MKT7nC5ylWaOVnbdW/sQKVJZ1eyDaiCR6T8OHap4J3QaLeElaWE=@vger.kernel.org X-Gm-Message-State: AOJu0YyylzxC1XJHoFVyw1socdYg+KWxTZkLSY2VRDP8U5R7jabt/Dsl +PPyRJstaaWMmhAUCBNenVbjXoQYE3KaCBY2TPnEYI33FoCLLrHXhaVluqzEb7ynEYw= X-Gm-Gg: Acq92OHIHdSezpdkosAG7F7jk2IoGHk2hJuKy6kp4qPsei8Rw/hrkD/R6uGIwMCG/m5 0fIRszxK4p4n8PRu1hBt1DdIibO54pfRLNy9BWoQ0+6WslF1umVgOVxLZsog06pmPL+MEKouetj 4YCEPkVBT2K5rqJ//Ad72MDN7dWvJ0aGtxkB1bmOzaTrcvM+AhnxfIMtE/XTJwjyj9625RNxHJ/ FmbJ4l2SsqWesK4r9M6L2t+cpRVo2ZUdjTdAuhH5J02fxi4kRLNU+1UKlq+Ofsl/xZHP2XK9ciC kAKpDnzDLuRRGMzbbtfjiI1dgkjw8uzXi9bK7e9xBlpWH9EnYH8HzGTiLbkYlzmS3IwsKYJA3MG JzPlcszOSThbR+ipQ9A8Zmb7cGyb9mbje1nm6a8+71mjYifZYenB0pMatA1c+1yBmXSk09U5Pc8 PNj3sAiVG0CGCezUkXKpbmNsvE9DfvFx9HGBk9WmelLrMWwa3IDk8+oun6SDsxhlg9YJaGx/xAi nsg4VcPpgfWJ9s5895FUkPyVwzNIgU= X-Received: by 2002:a05:622a:2488:b0:517:9544:163c with SMTP id d75a77b69052e-51795a08a3amr137404321cf.9.1780772450457; Sat, 06 Jun 2026 12:00:50 -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.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2026 12:00:49 -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 4/4] ceph: cap delegated inode count in ceph_parse_deleg_inos() Date: Sat, 6 Jun 2026 15:00:25 -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: quoted-printable Content-Type: text/plain; charset="utf-8" ceph_parse_deleg_inos() decodes interval sets of delegated inode numbers from an MDS create-with-delegation reply. For each set it reads a 64-bit start and a 64-bit len with ceph_decode_64_safe(), which only validates that the eight bytes are present in the message, not the value, and then loops over len while inserting entries into s_delegated_inos. len is fully attacker controlled. A malicious or compromised MDS can send one huge interval, many intervals in one reply, duplicate intervals, or repeated replies that accumulate delegated inodes on the same session. The v1 fix bounded only one interval and still allowed aggregate CPU and memory pressure. Bound both dimensions. Track the number of delegated inodes currently held by each MDS session, reject replies that would exceed that population cap, and also cap the total interval length accepted from one reply so duplicate ranges cannot spin through an attacker-controlled len while making no successful xarray inserts. The counter is decremented when async create consumes a delegated inode, incremented when a delegated inode is restored, initialized with the session xarray, and reset when reconnect destroys the xarray contents. The cap is a fixed, client-chosen constant rather than a value derived from the MDS. mds_client_prealloc_inos is a userspace MDS configuration option; it is never sent to the kernel client on the wire, and a server-supplied bound could not be trusted for a defensive limit in any case. The constant is set well above that option's documented default of 1000 (a generous multiple), so legitimate refill behavior is unaffected while the CPU and xarray memory a malformed delegation stream can consume stays bounded. Impact: a malicious or compromised Ceph MDS can no longer make a client spin through an unbounded delegated-inode interval or grow one session's delegated-inode xarray without limit. Fixes: d48464878708 ("ceph: decode interval_sets for delegated inos") Cc: stable@vger.kernel.org Suggested-by: Viacheslav Dubeyko Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito --- v2: - Replace the per-interval cap with a per-session delegated-inode population counter. - Add a per-reply interval budget so duplicate ranges cannot run the insertion loop without increasing the population counter. - Reset the counter when reconnect destroys the delegated-inode xarray. - Document why the cap is a fixed client-side constant (the kernel client cannot read the userspace mds_client_prealloc_inos option). fs/ceph/mds_client.c | 51 ++++++++++++++++++++++++++++++++++++++------ fs/ceph/mds_client.h | 1 + fs/ceph/super.h | 9 ++++++++ 3 files changed, 55 insertions(+), 6 deletions(-) diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c index 4f36ac73305dc..ec5a80c9f86a7 100644 --- a/fs/ceph/mds_client.c +++ b/fs/ceph/mds_client.c @@ -612,16 +612,34 @@ static int parse_reply_info_filelock(void **p, void *= end, =20 #define DELEGATED_INO_AVAILABLE xa_mk_value(1) =20 +static int ceph_insert_deleg_ino(struct ceph_mds_session *s, u64 ino) +{ + int err; + + if (atomic_inc_return(&s->s_num_deleg_inos) > CEPH_MAX_DELEG_INOS) { + atomic_dec(&s->s_num_deleg_inos); + return -EOVERFLOW; + } + + err =3D xa_insert(&s->s_delegated_inos, ino, DELEGATED_INO_AVAILABLE, + GFP_KERNEL); + if (err) + atomic_dec(&s->s_num_deleg_inos); + return err; +} + static int ceph_parse_deleg_inos(void **p, void *end, struct ceph_mds_session *s) { struct ceph_client *cl =3D s->s_mdsc->fsc->client; + u64 msg_deleg_inos =3D 0; u32 sets; =20 ceph_decode_32_safe(p, end, sets, bad); doutc(cl, "got %u sets of delegated inodes\n", sets); while (sets--) { u64 start, len; + int session_deleg_inos; =20 ceph_decode_64_safe(p, end, start, bad); ceph_decode_64_safe(p, end, len, bad); @@ -633,16 +651,34 @@ static int ceph_parse_deleg_inos(void **p, void *end, start, len); continue; } + + if (len > CEPH_MAX_DELEG_INOS || + msg_deleg_inos > CEPH_MAX_DELEG_INOS - len) { + pr_warn_ratelimited_client(cl, "too many delegated inodes in reply\n"); + return -EIO; + } + + session_deleg_inos =3D atomic_read(&s->s_num_deleg_inos); + if (session_deleg_inos > CEPH_MAX_DELEG_INOS || + len > CEPH_MAX_DELEG_INOS - session_deleg_inos) { + pr_warn_ratelimited_client(cl, "too many delegated inodes for session\n= "); + return -EIO; + } + + msg_deleg_inos +=3D len; + while (len--) { - int err =3D xa_insert(&s->s_delegated_inos, start++, - DELEGATED_INO_AVAILABLE, - GFP_KERNEL); + int err =3D ceph_insert_deleg_ino(s, start++); + if (!err) { doutc(cl, "added delegated inode 0x%llx\n", start - 1); } else if (err =3D=3D -EBUSY) { pr_warn_client(cl, "MDS delegated inode 0x%llx more than once.\n", start - 1); + } else if (err =3D=3D -EOVERFLOW) { + pr_warn_ratelimited_client(cl, "too many delegated inodes\n"); + return -EIO; } else { return err; } @@ -660,16 +696,17 @@ u64 ceph_get_deleg_ino(struct ceph_mds_session *s) =20 xa_for_each(&s->s_delegated_inos, ino, val) { val =3D xa_erase(&s->s_delegated_inos, ino); - if (val =3D=3D DELEGATED_INO_AVAILABLE) + if (val =3D=3D DELEGATED_INO_AVAILABLE) { + atomic_dec(&s->s_num_deleg_inos); return ino; + } } return 0; } =20 int ceph_restore_deleg_ino(struct ceph_mds_session *s, u64 ino) { - return xa_insert(&s->s_delegated_inos, ino, DELEGATED_INO_AVAILABLE, - GFP_KERNEL); + return ceph_insert_deleg_ino(s, ino); } #else /* BITS_PER_LONG =3D=3D 64 */ /* @@ -1056,6 +1093,7 @@ static struct ceph_mds_session *register_session(stru= ct ceph_mds_client *mdsc, INIT_LIST_HEAD(&s->s_waiting); INIT_LIST_HEAD(&s->s_unsafe); xa_init(&s->s_delegated_inos); + atomic_set(&s->s_num_deleg_inos, 0); INIT_LIST_HEAD(&s->s_cap_releases); INIT_WORK(&s->s_cap_release_work, ceph_cap_release_work); =20 @@ -4971,6 +5009,7 @@ static void send_mds_reconnect(struct ceph_mds_client= *mdsc, goto fail_nomsg; =20 xa_destroy(&session->s_delegated_inos); + atomic_set(&session->s_num_deleg_inos, 0); =20 mutex_lock(&session->s_mutex); session->s_state =3D CEPH_MDS_SESSION_RECONNECTING; diff --git a/fs/ceph/mds_client.h b/fs/ceph/mds_client.h index 4e6c87f8414cc..3810b51ece2e6 100644 --- a/fs/ceph/mds_client.h +++ b/fs/ceph/mds_client.h @@ -255,6 +255,7 @@ struct ceph_mds_session { struct list_head s_waiting; /* waiting requests */ struct list_head s_unsafe; /* unsafe requests */ struct xarray s_delegated_inos; + atomic_t s_num_deleg_inos; }; =20 /* diff --git a/fs/ceph/super.h b/fs/ceph/super.h index afc89ce91804e..bfc26e4d83bb4 100644 --- a/fs/ceph/super.h +++ b/fs/ceph/super.h @@ -634,6 +634,15 @@ static inline int ceph_ino_compare(struct inode *inode= , void *data) #define CEPH_MDS_INO_LOG_OFFSET (2 * CEPH_MAX_MDS) #define CEPH_INO_SYSTEM_BASE ((6*CEPH_MAX_MDS) + (CEPH_MAX_MDS * CEPH_NUM= _STRAY)) =20 +/* + * Upper bound on the number of delegated inodes a single MDS session may + * hold. The MDS normally hands out a small preallocation window (the + * userspace mds_client_prealloc_inos option defaults to 1000) and refills + * it as the client consumes entries. This leaves generous headroom while + * bounding the CPU and memory a malformed delegation interval can consume. + */ +#define CEPH_MAX_DELEG_INOS 8192 + static inline bool ceph_vino_is_reserved(const struct ceph_vino vino) { if (vino.ino >=3D CEPH_INO_SYSTEM_BASE || --=20 2.53.0