[{"id":3677436,"web_url":"http://patchwork.ozlabs.org/comment/3677436/","msgid":"","list_archive_url":null,"date":"2026-04-15T02:00:58","subject":"Re: [PATCH 1/3] ksmbd: cap response sizes in ipc_validate_msg()","submitter":{"id":79386,"url":"http://patchwork.ozlabs.org/api/people/79386/","name":"Namjae Jeon","email":"linkinjeon@kernel.org"},"content":"On Wed, Apr 15, 2026 at 4:15 AM Michael Bommarito\n wrote:\n>\n> ipc_validate_msg() computes the expected message size for each\n> response type by adding (or multiplying) attacker-controlled fields\n> from the daemon response to a fixed struct size in unsigned int\n> arithmetic. Three cases can overflow:\n>\n> KSMBD_EVENT_RPC_REQUEST:\n> msg_sz = sizeof(struct ksmbd_rpc_command) + resp->payload_sz;\n> KSMBD_EVENT_SHARE_CONFIG_REQUEST:\n> msg_sz = sizeof(struct ksmbd_share_config_response) +\n> resp->payload_sz;\n> KSMBD_EVENT_LOGIN_REQUEST_EXT:\n> msg_sz = sizeof(struct ksmbd_login_response_ext) +\n> resp->ngroups * sizeof(gid_t);\n>\n> resp->payload_sz is __u32 and resp->ngroups is __s32. Each addition\n> can wrap in unsigned int; the multiplication by sizeof(gid_t) mixes\n> signed and size_t, so a negative ngroups is converted to SIZE_MAX\n> before the multiply. A wrapped value of msg_sz that happens to\n> equal entry->msg_sz bypasses the size check on the next line, and\n> downstream consumers (smb2pdu.c:6742 memcpy using rpc_resp->payload_sz,\n> kmemdup in ksmbd_alloc_user using resp_ext->ngroups) then trust the\n> unverified length.\n>\n> This is the response-side analogue of aab98e2dbd64 (\"ksmbd: fix\n> integer overflows on 32 bit systems\"), which hardened the request\n> side by bounding attacker-controlled lengths against the existing\n> KSMBD_IPC_MAX_PAYLOAD / NGROUPS_MAX caps. Apply the same caps on\n> the response side: reject resp->payload_sz > KSMBD_IPC_MAX_PAYLOAD\n> for RPC_REQUEST and SHARE_CONFIG_REQUEST, and reject resp->ngroups\n> outside the signed [0, NGROUPS_MAX] range for LOGIN_REQUEST_EXT.\n> With those caps the subsequent additions and multiplication are\n> bounded well below UINT_MAX.\n>\n> Fixes: 0626e6641f6b (\"cifsd: add server handler for central processing and tranport layers\")\n> Cc: stable@vger.kernel.org\n> Assisted-by: Claude:claude-opus-4-6\n> Assisted-by: Codex:gpt-5-4\n> Signed-off-by: Michael Bommarito \n> ---\n> fs/smb/server/transport_ipc.c | 7 ++++++-\n> 1 file changed, 6 insertions(+), 1 deletion(-)\n>\n> diff --git a/fs/smb/server/transport_ipc.c b/fs/smb/server/transport_ipc.c\n> --- a/fs/smb/server/transport_ipc.c\n> +++ b/fs/smb/server/transport_ipc.c\n> @@ -497,6 +497,8 @@ static int ipc_validate_msg(struct ipc_msg_table_entry *entry)\n> {\n> struct ksmbd_rpc_command *resp = entry->response;\n>\n> + if (resp->payload_sz > KSMBD_IPC_MAX_PAYLOAD)\n> + return -EINVAL;\nHowever, on the userspace side (ksmbd-tools/mountd/rpc.c), the DCE/RPC\nresponse builder (try_realloc_payload() and ndr_write_bytes())\ndynamically grows the payload by 4096 bytes using g_try_realloc() when\npreparing responses for calls such as NetShareEnumAll, etc..\nThis can cause share enumeration failures on servers with many shares.\n\n> msg_sz = sizeof(struct ksmbd_rpc_command) + resp->payload_sz;\n> break;\n> }\n> @@ -513,7 +515,8 @@ static int ipc_validate_msg(struct ipc_msg_table_entry *entry)\n> struct ksmbd_share_config_response *resp = entry->response;\n>\n> if (resp->payload_sz) {\n> - if (resp->payload_sz < resp->veto_list_sz)\n> + if (resp->payload_sz < resp->veto_list_sz ||\n> + resp->payload_sz > KSMBD_IPC_MAX_PAYLOAD)\n> return -EINVAL;\nYou don't add the check for KSMBD_EVENT_SPNEGO_AUTHEN_REQUEST case.\nWe don't need to check resp->session_key_len and resp->spnego_blob_len?","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-cifs@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=iHUuRHyV;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-cifs+bounces-10823-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"iHUuRHyV\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwPZl0BD4z1yHc\n\tfor ; Wed, 15 Apr 2026 12:03:58 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id A7F533087973\n\tfor ; Wed, 15 Apr 2026 02:01:13 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id B21203090D7;\n\tWed, 15 Apr 2026 02:01:12 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 8F801303C8A\n\tfor ; Wed, 15 Apr 2026 02:01:12 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 4AFA7C2BCB5\n\tfor ; Wed, 15 Apr 2026 02:01:12 +0000 (UTC)","by mail-ej1-f52.google.com with SMTP id\n a640c23a62f3a-b9c280322e0so757144066b.0\n for ;\n Tue, 14 Apr 2026 19:01:12 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776218472; cv=none;\n b=fa6WamKu5pPiCSVym4I/xTuAFrGCVLmEjHBbVcaf3FztzvwpOZ5CJ4WLNmENgHdwWGxpbBsCsxNaLkgpWWO5JhORJuxNccXP0NAWcSrHxkuFnu7lpHynfN3zdh1+Pxjb6Qdks97xXywCH1cr8aTaDpxpP9Ee/Bro1RaC6vd91Bc=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776218472; c=relaxed/simple;\n\tbh=8YVeNgNiRmAJqMrVc5F669ogu0IKs8pMHti83cSxKJE=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=e0y9ZXialexz1alfLXFg1+s+I+9WWPsr2HaEK46QpV/hmdsrXTymoHFC99SNDgtY2rOB39nweYDqB1nc9DrP1bqRjj8/n0mXhdMjt8ZcbP32xfe8k6N9iocORtWljjMchjOmKuCSb6KQjlvubYYzjUXzex9fmbXi7DGTYxrb8ig=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=iHUuRHyV; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1776218472;\n\tbh=8YVeNgNiRmAJqMrVc5F669ogu0IKs8pMHti83cSxKJE=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=iHUuRHyVek5CKaP2mf8cyKNQ5W/cP9kHJ5I6FyDpk7eSNdQPelQMKmBq+p3xKJM65\n\t 4rIBPehTP/wtGVtCRWR1pXLOKV6hAXf4TIpmATKqbHurUfGjPrwKpHWzsN/7BUXZSm\n\t tuFUbuQNVX+yRZ4KjZFl1lCqeUbmYEyfUrGR9uG/ZvbB4SNP/Mgxd9v5VdnV5QZEK1\n\t 6jkb9xLFzhQ9iCTlyIClcOfOl+R3iu256kJgB4XBd/V4pmyylaLWgURd9L5JX7T+Rf\n\t QDGGQj+aOpmlKXOZWiz3mW9JfUVACjHt5NdYBZJ6IxDB2lKjyygS3oVES+Anz/EJ1k\n\t VfLEf8JOAeRFw==","X-Gm-Message-State":"AOJu0YxteWlU99N4KokVp1eEqYdRXwAi1tIYTiAcXPs0ug/TluzKwUM4\n\tCj240+2AsghXWw2E5u6oEtRsGvZ2VV0KcnG4q7v2FbiwSS0bVLopZwzt9i0mg4fMcXmVC2o0tle\n\tmNRgmBgVdlwGrI0ana9By5zRRCaX3ks4=","X-Received":"by 2002:a17:907:3e8a:b0:b9c:eedb:db4 with SMTP id\n a640c23a62f3a-b9d727a0607mr1017965666b.53.1776218470846; Tue, 14 Apr 2026\n 19:01:10 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-cifs@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<20260414191533.1467353-1-michael.bommarito@gmail.com>\n <20260414191533.1467353-2-michael.bommarito@gmail.com>","In-Reply-To":"<20260414191533.1467353-2-michael.bommarito@gmail.com>","From":"Namjae Jeon ","Date":"Wed, 15 Apr 2026 11:00:58 +0900","X-Gmail-Original-Message-ID":"\n ","X-Gm-Features":"AQROBzDiTpeN0_4j4Q3OmL-_lPLc4Vt6-gETxOY7I8KyeY9SyNLI3Hhpqk1YlDs","Message-ID":"\n ","Subject":"Re: [PATCH 1/3] ksmbd: cap response sizes in ipc_validate_msg()","To":"Michael Bommarito ","Cc":"linux-cifs@vger.kernel.org, Steve French ,\n\tSergey Senozhatsky , Tom Talpey ,\n stable@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}}]