Received: by 2002:a05:7412:f584:b0:e2:908c:2ebd with SMTP id eh4csp1931098rdb; Tue, 5 Sep 2023 09:07:07 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEPgDmUiJf4nttoN6SuIKrCpO5G/EOj3Sz0EReUuuWaG3Xz8rdb5Vxqxn8MuoAqqgRieNJ3 X-Received: by 2002:ac2:4a74:0:b0:4f9:5ca5:f1a6 with SMTP id q20-20020ac24a74000000b004f95ca5f1a6mr225872lfp.17.1693930027337; Tue, 05 Sep 2023 09:07:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1693930027; cv=none; d=google.com; s=arc-20160816; b=Ianm9Kv5WgpF++krqFAv/E1UEOv/jv6TgmMTRE38TslOQBcmk75CSX0Ts6DvhgiNzm WaQt68y/UzY2a+ukRkVHYIoxSurqTJrklqxLKkueloFa/WItVE9odlCNT561cB6KYMTQ SDXDL7uNpANDV+jRbvpAaUSQQo7fJwWXIzl4U2MNABfFACTpRPSSaIizX+F2lTj2tNVv 9TAdsJE7Jvyd+fPDjmcamwi4AF0OZSsLqR6nuiTfSsCj91vXC8lrjqqugytLuCqa7ktS R8pbvLLyaik8OVGbIwUtz94SEG4cvyRROGyGXMT4/gIHjt00043hQ7ubNW7a+U5d9+R2 KI8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=ioVA0HjI/cemLn82R6FloaV9808frnfpiYwZaHczoH4=; fh=TFobPSvmLyGDNPcAEs3yB7kZw4YN+Pmw5X2CijJ4m98=; b=gX3wQLBUqIuH0zSXAWqQZPYIPsUJSAZeXYSIND/II1uSIH24NYZGHu8AQY97A34AdL ZRLkdPOsCDlteAJzecVsMZq+uVz+ysky/TXJkfFVVFtOcUgUSENjqqcKi8FYrn6vlv0O P7q2Xc02LIVE9b6sGk52BXGnMuigWfdso9NodHYNEGMfwHYnswtMTcx9cq1MWLGGs3pC 0CBLX4cACfyDZQmyJJBbLZxo232WaQe/W4BO0FSy9Xn65sPrB3T8101nKXG+ye79v1Rj SjROj+BeAo/bc/AX1xNUOBgC8Fq7yUKO0ksLZrlsk5SqbFEgV0ieZLwRmITEvaZ/iT8P tiUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b=C+m22130; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dk20-20020a170906f0d400b00992bbdebdbesi7563816ejb.785.2023.09.05.09.07.00; Tue, 05 Sep 2023 09:07:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b=C+m22130; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349743AbjIANay (ORCPT + 10 others); Fri, 1 Sep 2023 09:30:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44154 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233654AbjIANax (ORCPT ); Fri, 1 Sep 2023 09:30:53 -0400 Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9ED17CDD; Fri, 1 Sep 2023 06:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1693575047; bh=pkbbGagA3i0Bnj+ku0lHfhSJzOGz2/XYlf1w4l2JIXg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=C+m22130Lvzn8GrGf2sOmSHmowFiKfvj2xHtVhvj+F360XM5OiSSWolq8QmacTOmb px8FcNRPIgEhiJpBA5iCTdIIiZ6Q7CqA6A4/JoCo812tJTE2f6QSzpsp2qtMiYgHF8 govH2PsztIGIcVW6WGrHb1N0HVleMndq+lH7X/NQArDU/VTmRCEmgL0mvmokLZOKmu AkTbEJqqiCJi5t7Uvh89OUZnpKqffcm7NbzG4ozxSnPlPDFpeLfo2QlOkkumpRjHRw TDufzeNKLVk1EuByVhgok6eLUitHOqj+iQftaw6Vm1NwnBtffHvP5+8TqWDe+R5yY2 1L7zjkYl+mwRA== Received: from [IPV6:2606:6d00:100:4000:cacb:9855:de1f:ded2] (unknown [IPv6:2606:6d00:100:4000:cacb:9855:de1f:ded2]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4Rcf6v1FR8z1Ml2; Fri, 1 Sep 2023 09:30:47 -0400 (EDT) Message-ID: Date: Fri, 1 Sep 2023 09:31:58 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH] srcu: The value may overflow Content-Language: en-US To: Denis Arefev , Lai Jiangshan Cc: "Paul E. McKenney" , Josh Triplett , Steven Rostedt , rcu@vger.kernel.org, lvc-project@linuxtesting.org, linux-kernel@vger.kernel.org, trufanov@swemel.ru, vfh@swemel.ru References: <20230901095341.55857-1-arefev@swemel.ru> From: Mathieu Desnoyers In-Reply-To: <20230901095341.55857-1-arefev@swemel.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/1/23 05:53, Denis Arefev wrote: > The value of an arithmetic expression 1 << (cpu - sdp->mynode->grplo) > is subject to overflow due to a failure to cast operands to a larger > data type before performing arithmetic > > Found by Linux Verification Center (linuxtesting.org) with SVACE. > > Signed-off-by: Denis Arefev > --- > kernel/rcu/srcutree.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c > index 20d7a238d675..e14b74fb1ba0 100644 > --- a/kernel/rcu/srcutree.c > +++ b/kernel/rcu/srcutree.c > @@ -223,7 +223,7 @@ static bool init_srcu_struct_nodes(struct srcu_struct *ssp, gfp_t gfp_flags) > snp->grplo = cpu; > snp->grphi = cpu; > } > - sdp->grpmask = 1 << (cpu - sdp->mynode->grplo); > + sdp->grpmask = 1UL << (cpu - sdp->mynode->grplo); What possible values of cpus supported by the Linux kernel and grplo can cause this to overflow on 64-bit architectures ? I suspect the maximum result of this subtraction is defined by the RCU_FANOUT or other srcu level-spread values assigned by rcu_init_levelspread(), which can indeed cause the signed 32-bit integer literal ("1") to overflow when shifted by any value greater than 31. This analysis should be added to the commit message so the impact of the issue can be understood. I also notice this in the same file: srcu_schedule_cbs_snp(): for (cpu = snp->grplo; cpu <= snp->grphi; cpu++) { if (!(mask & (1 << (cpu - snp->grplo)))) continue; Which should be fixed at the same time. Thanks, Mathieu > } > smp_store_release(&ssp->srcu_sup->srcu_size_state, SRCU_SIZE_WAIT_BARRIER); > return true; -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com