From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 51820298CC7 for ; Sat, 15 Nov 2025 17:02:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763226181; cv=none; b=TpV47lBdK5e97BmIXOn+fzdm8LOZZbWP6rSJErMVf/FCK59H3RDbvQ7EU7vOTO9hpdVSs2ViWzJxCGKKOQtvl8sLoA2ddQOw9r6oiPW3KtQaTip/zP0i/4IjfzhBGUz04uBqIU1DzMgB1n8PvF3i0JZDlKh0nNUn9zTW70cX6sU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763226181; c=relaxed/simple; bh=Ynsp4AGIiFvIUjzx33S0RcH+iZzWSG7GvDrxPYpl5y0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dobsOXnTD11iQUvX+RD+Qq0HEIve7OEJXVJubQcyME1TnT710hTNSEPkeExdYRUcTQEL6ywuMUbFfQdJcDfTxX00Q5R09kitw8lS9OCk7snnB/Mjqg+HU5y9w5imzg1Db7bfDW6abi9D+5O9qvw3EKWttWZwe1ZCWEZS29LlhT8= 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=UxlJbrVM; arc=none smtp.client-ip=209.85.128.46 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="UxlJbrVM" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-477632b0621so19553395e9.2 for ; Sat, 15 Nov 2025 09:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763226178; x=1763830978; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=fhZf0daDzyc4x+cTxD8gsx/UNr12/kXrHW7QrRdshYk=; b=UxlJbrVMoJ7bnxVGwt8oiDKH6qqyQjMInsErS/GhB4nPtiODa8tfUKPgiFhp71B8BO 40g/sbzfpIfFe07FXzjIfp8EmjzjoBOZ4VkKbzM7lkTqVJwCiYI7+1OVFOfLJVQz6i4K UEiOh46zFz9Fcp6Y8kM5600faujRYJwiXYuNaVEBOnQhEFpzPtXOWJ4i0KonEm6dyK7n LpJ8HIMDhi3FA+NcC0lfypmSVGY5vONUs5RAiONHmTiHmZPEiUM1J9IjLojtLjnbuR0r 0ZhME8ekeafa/azI4xQwhX58uxfHeW8wqJcHqiSwvX4VPGxNvj1qHX5Nu06xS+J1aw4I uesA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763226178; x=1763830978; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=fhZf0daDzyc4x+cTxD8gsx/UNr12/kXrHW7QrRdshYk=; b=gSzKjXHO3dNaQTHBPZ6C2CCUBqJSvFpAK/Zv+0SSeWvj59xiYM9MB0V+uSJvP6Znk9 ZLm5F5irOQaozNU5xTklDLlUu96Q+aRRwEJCNaorVGawOrrGY0kdOwZREXKSZD/AcyGx UzxAmHDjEWA7ejYoOU0EJ3C2G9DBZ+7zaeDyeY+aDYQy496hJ2MbjatfkHIZQz38CJmt 8nfPyrif4UwKTYKJBNiYcf87Zll1lZLuphR6q4mMVhn1uNZRsunCpY1AUUt0EA688P/7 JFByDI7y/dnA3GaQEHDwTrPfHtzv+vcyXjpGQ6WTyKsLI+5p2UNj5nka2vVP1RvF5bNP 86Gg== X-Forwarded-Encrypted: i=1; AJvYcCUMrFVjJ6T0A1iVvkNGQGAlgdgSHWJ2Lja//Jk4ACcpVquEq11q7d5naJyZrQ103/aYZIDGUHkHeuJ05mI=@vger.kernel.org X-Gm-Message-State: AOJu0YxX+pgsxxL5SqbpXBinfFJZ1BjQ+ovHV3sUJt1Dcu9e70bMnTTd iXsYJ7bv6vgEnOl9erEQ3tN7e/qdPybDOFf6Yc0LKIho6MlfpgsZBjPb X-Gm-Gg: ASbGnctlQA5nCf8YMna4EUVmKJ3gL8gts6a24fAJYOqE5MfHno4jDnVH9hqt0ozRCTG /4YUEv4l79DOkPgTa6xUs3ilkCkw5SEtyJjvw/Rb9rBGMtH7wkzpH8xIjRHeF0/SexHiAjiB7wr MbS+iCkuFJEYNIwjZQKlkaJvMOh4bSo3CqA7VyD/doZCpCmMvDJ1ybKzRt+P6MfzidwTX6nhmcR m+MAJHbK1Kv/tvimP1pTJHrNn6IEPg2ofdEWTSGq9L2spFs6Bhc4XAGXcRTW0vjycmJ761rBq7k VhbX2nB723g35jMMNF/WC/S+TVwJBuWgnQTlOe4NGEVGFrAgMayXcr/vaKpL+ILv83cfB59Gver uMYsKlszqeau4u+Jl52mh4py/jMOCjeGH4T+wVlFvF3UxXjhWzNomuZZCQimAcLBOsC40bMmFzA rfQBLU+qPDay7ZsChHL0YkRCi/dIzlRUqLbxpY4N/41952yDOqcJzqZKrRchThu1A= X-Google-Smtp-Source: AGHT+IGvA6Cf0hX6CHFmLOv2ERiNOSbof9VojTgyNbFZ08X3ubaL0BT4MHWHB1qRipjBox5egLNWRg== X-Received: by 2002:a05:600c:4513:b0:477:5cc6:7e44 with SMTP id 5b1f17b1804b1-4778fe5de1amr68131925e9.11.1763226177303; Sat, 15 Nov 2025 09:02:57 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4778bb34cc1sm71532425e9.3.2025.11.15.09.02.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Nov 2025 09:02:57 -0800 (PST) Date: Sat, 15 Nov 2025 17:02:53 +0000 From: David Laight To: Qianchang Zhao Cc: Namjae Jeon , Steve French , gregkh@linuxfoundation.org, linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org, Zhitong Liu , stable@vger.kernel.org Subject: Re: [PATCH v2] ksmbd: vfs_cache: avoid integer overflow in inode_hash() Message-ID: <20251115170253.64ee8828@pumpkin> In-Reply-To: <20251115144836.555128-1-pioooooooooip@gmail.com> References: <20251115144836.555128-1-pioooooooooip@gmail.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 15 Nov 2025 23:48:36 +0900 Qianchang Zhao wrote: > inode_hash() currently mixes a hash value with the super_block pointer > using an unbounded multiplication: > > tmp = (hashval * (unsigned long)sb) ^ > (GOLDEN_RATIO_PRIME + hashval) / L1_CACHE_BYTES; > > On 64-bit kernels this multiplication can overflow and wrap in unsigned > long arithmetic. The same happens on 32bits. > While this is not a memory-safety issue, it is an > unbounded integer operation and weakens the mixing properties of the > hash. Are you sure, I'd have thought all the 'carry' operations in the multiply would make it better. > Replace the pointer*hash multiply with hash_long() over a mixed value > (hashval ^ (unsigned long)sb) and keep the existing shift/mask. This > removes the overflow source and reuses the standard hash helper already > used in other kernel code. > > This is an integer wraparound / robustness issue (CWE-190/CWE-407), > not a memory-safety bug. It isn't really an integer wraparound bug either. The fact that only the low bits of the product are used shouldn't matter at all. OTOH it might be worth sifting 'sb' right some bits - quite a few of its low bits are zero and they end up as zeros in the product. David > > Reported-by: Qianchang Zhao > Reported-by: Zhitong Liu > Cc: stable@vger.kernel.org > Signed-off-by: Qianchang Zhao > --- > fs/smb/server/vfs_cache.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/fs/smb/server/vfs_cache.c b/fs/smb/server/vfs_cache.c > index dfed6fce8..a62ea5aae 100644 > --- a/fs/smb/server/vfs_cache.c > +++ b/fs/smb/server/vfs_cache.c > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include > > #include "glob.h" > #include "vfs_cache.h" > @@ -65,12 +66,8 @@ static void fd_limit_close(void) > > static unsigned long inode_hash(struct super_block *sb, unsigned long hashval) > { > - unsigned long tmp; > - > - tmp = (hashval * (unsigned long)sb) ^ (GOLDEN_RATIO_PRIME + hashval) / > - L1_CACHE_BYTES; > - tmp = tmp ^ ((tmp ^ GOLDEN_RATIO_PRIME) >> inode_hash_shift); > - return tmp & inode_hash_mask; > + unsigned long mixed = hashval ^ (unsigned long)sb; > + return hash_long(mixed, inode_hash_shift) & inode_hash_mask; > } > > static struct ksmbd_inode *__ksmbd_inode_lookup(struct dentry *de)