Message ID | 20221121075618.15877-1-korotkov.maxim.s@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1443410wrr; Sun, 20 Nov 2022 23:59:47 -0800 (PST) X-Google-Smtp-Source: AA0mqf7qIuOAUMURagBO3BUmLquA/RbxX6NdsmNBfXg86naZYrFYtpbza5bR8FrahdO7K7BDcLMG X-Received: by 2002:a05:6402:520b:b0:464:718c:b271 with SMTP id s11-20020a056402520b00b00464718cb271mr15206301edd.287.1669017587167; Sun, 20 Nov 2022 23:59:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669017587; cv=none; d=google.com; s=arc-20160816; b=HXoR431Rp9H2ca+OXDoYc7pPinC01OnTWDgSyAv+sy9pt8ikXYJKXL/SYG8Mhpo6bj xk8eTk81G6FCV1QHgOF/xeuFtKvbL0gn2XX6stIkWSK5LuJi5QuishvoKwgEo42gFg9Q nRPVnU7zi0jjRHCpIOIuSXtg4MFAb9SpPhx1UdeKxrytZDly63zVlOTtprLi+96wX2v8 AiqTROPyzgQaGdk0UjEgUJF57c+ghBI1O46aQfeDkQ6sqkoNvo93LjbdGL0IrW8k2zUh MLLrx1SX73kDCKUAQlrtV1SivqLjTyYxRExMY/boJTlDGezX8Tr38gY02sPYrmDGFWcA AzzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature; bh=Vs2l23NxmyfDzTeykhjw4XnqjbPvSyKWp0TKAT504Gs=; b=0R78PRWKJEMsI8gny1Penu9sbBj12Sj3UhZ3rBfT5sOmiZ831Xx2JACTZNTXXI+O/Y F5eAzPxTrbDv7MryuRtZaLTo+tbAxjrfRVplbntKniGQgiHtTxlgfHSyIcmM8ABEZkqL IVK4OpLn+rzCi1Pc283hjKoLcclNhxKkmyD8Ww9KKNyz00R5jTqFUEBx/5ZKEBgbRGa3 qscgyIz/etvyRLeg/dGvgNBuUqBiE9OOR6KC35GslCCxm4JUpBubOgjqwOhKV68veVZP BhSnDphnq+vIwWNK3YPlo9KmtEe2xDWlhXSBylppQwrPEzoexYsP008uVrLnxsG4VnUN pjjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=qZ5TqP+t; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g5-20020a1709065d0500b0073fc8e72882si10781682ejt.28.2022.11.20.23.59.21; Sun, 20 Nov 2022 23:59:47 -0800 (PST) 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=@gmail.com header.s=20210112 header.b=qZ5TqP+t; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229774AbiKUH5T (ORCPT <rfc822;peter110.wang@gmail.com> + 99 others); Mon, 21 Nov 2022 02:57:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35062 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229632AbiKUH5S (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 21 Nov 2022 02:57:18 -0500 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 57C48BC04; Sun, 20 Nov 2022 23:57:17 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id j4so17670274lfk.0; Sun, 20 Nov 2022 23:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Vs2l23NxmyfDzTeykhjw4XnqjbPvSyKWp0TKAT504Gs=; b=qZ5TqP+tU7NjssMr6vD8VJ70uIGXA+SK4QPz6fglRMTHclkDx/hz9TcruN6hw9XTMk JuDdr5vV0v8XrXshakEitOkB1K6RHeaTBIW8uLhJBYjJKS+w3nF8WjxgmpciZIrcK2mY EloizFriSWMWsMxGPDDXwtsqtUJWdhPJAWgzwkkUQ9sWpYS2zAFBLVLjPntiIfHmWkzP TMeuFaRBQn7q9M69nb6JF/hMrFzHs5mgtLQbScUVKQf9DgjmMHmbT6rFsPfS86MMMJhQ w64IGNmISHNJ9A9zzBV1v/z8YG7o1cnFIddNGfhMGdOZxxFWY/af1ti5gTHGynLLQtWe C2LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Vs2l23NxmyfDzTeykhjw4XnqjbPvSyKWp0TKAT504Gs=; b=0BMn/r6N/ZuFFi8Tg13IwmrUoJ7RvwYHgt3S8HYJ8rhgofXRmu340nNcy0Pysh9vBE +hCral1ClY1yzjiKTZHaynAy/1BV6i0FXvEJXwagdbsUvkoYLIen0RQxcXrzqPbu+MmS 4OJ+SF9yoh+CmzADvwpTI0Jll/Z41UFYBmL49MSdDOh2g8Yhofk1O4GabouN7QIlFMFB bBBJaqhFv4gsIP5ee43Na/rHLRKW7jSDuGKUrv3TMpG9nmilAHn+RcX6XoUQ91RLWcDR nr2Q50Kv9r9qZv0XoOgxUf+XTzKX2CTlJPrceHuI14uVSruPyjhhuTmwLCZuLvXGcdah o0sA== X-Gm-Message-State: ANoB5pmn2usfSCjVcJ5JaIZ001zeMyWk0wcAknID7Zg4m6RVlplGI89e YlL3dWhytPeyndGRYEadVh/gr2nLiFn9yIiQ9Idt3w== X-Received: by 2002:a05:6512:280e:b0:4a2:5154:ead9 with SMTP id cf14-20020a056512280e00b004a25154ead9mr5836045lfb.32.1669017435541; Sun, 20 Nov 2022 23:57:15 -0800 (PST) Received: from mkor.rasu.local ([212.22.67.162]) by smtp.gmail.com with ESMTPSA id y18-20020a05651c107200b0027741daec09sm1292904ljm.107.2022.11.20.23.57.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Nov 2022 23:57:15 -0800 (PST) From: Maxim Korotkov <korotkov.maxim.s@gmail.com> To: "David S. Miller" <davem@davemloft.net> Cc: Maxim Korotkov <korotkov.maxim.s@gmail.com>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Guangbin Huang <huangguangbin2@huawei.com>, Andrew Lunn <andrew@lunn.ch>, Tom Rix <trix@redhat.com>, Marco Bonelli <marco@mebeim.net>, Edward Cree <ecree@solarflare.com>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org Subject: [PATCH] ethtool: avoiding integer overflow in ethtool_phys_id() Date: Mon, 21 Nov 2022 10:56:18 +0300 Message-Id: <20221121075618.15877-1-korotkov.maxim.s@gmail.com> X-Mailer: git-send-email 2.17.1 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750091785023413456?= X-GMAIL-MSGID: =?utf-8?q?1750091785023413456?= |
Series |
ethtool: avoiding integer overflow in ethtool_phys_id()
|
|
Commit Message
Maxim Korotkov
Nov. 21, 2022, 7:56 a.m. UTC
The value of an arithmetic expression "n * id.data" is subject
to possible overflow due to a failure to cast operands to a larger data
type before performing arithmetic. Added cast of first operand to u64
for avoiding overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 2adc6edcaec0 ("ethtool: fix error handling in ethtool_phys_id")
Signed-off-by: Maxim Korotkov <korotkov.maxim.s@gmail.com>
---
net/ethtool/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Mon, Nov 21, 2022 at 10:56:18AM +0300, Maxim Korotkov wrote: > The value of an arithmetic expression "n * id.data" is subject > to possible overflow due to a failure to cast operands to a larger data > type before performing arithmetic. Added cast of first operand to u64 > for avoiding overflow. > > Found by Linux Verification Center (linuxtesting.org) with SVACE. > > Fixes: 2adc6edcaec0 ("ethtool: fix error handling in ethtool_phys_id") > Signed-off-by: Maxim Korotkov <korotkov.maxim.s@gmail.com> > --- > net/ethtool/ioctl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c > index 6a7308de192d..cf87e53c2e74 100644 > --- a/net/ethtool/ioctl.c > +++ b/net/ethtool/ioctl.c > @@ -2007,7 +2007,7 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr) > } else { > /* Driver expects to be called at twice the frequency in rc */ > int n = rc * 2, interval = HZ / n; > - u64 count = n * id.data, i = 0; > + u64 count = (u64)n * id.data, i = 0; How about moving the code around a bit, change n to a u64 and drop the cast? Does this look correct? int interval = HZ / rc / 2; u64 n = rc * 2; u64 count = n * id.data; i = 0; I just don't like casts, they suggest the underlying types are wrong, so should fix that, not add a cast. Andrew
From: Andrew Lunn <andrew@lunn.ch> Date: Mon, 21 Nov 2022 15:10:18 +0100 > On Mon, Nov 21, 2022 at 10:56:18AM +0300, Maxim Korotkov wrote: > > The value of an arithmetic expression "n * id.data" is subject > > to possible overflow due to a failure to cast operands to a larger data > > type before performing arithmetic. Added cast of first operand to u64 > > for avoiding overflow. > > > > Found by Linux Verification Center (linuxtesting.org) with SVACE. > > > > Fixes: 2adc6edcaec0 ("ethtool: fix error handling in ethtool_phys_id") > > Signed-off-by: Maxim Korotkov <korotkov.maxim.s@gmail.com> > > --- > > net/ethtool/ioctl.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c > > index 6a7308de192d..cf87e53c2e74 100644 > > --- a/net/ethtool/ioctl.c > > +++ b/net/ethtool/ioctl.c > > @@ -2007,7 +2007,7 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr) > > } else { > > /* Driver expects to be called at twice the frequency in rc */ > > int n = rc * 2, interval = HZ / n; > > - u64 count = n * id.data, i = 0; > > + u64 count = (u64)n * id.data, i = 0; > > > How about moving the code around a bit, change n to a u64 and drop the > cast? Does this look correct? > > int interval = HZ / rc / 2; > u64 n = rc * 2; > u64 count = n * id.data; > > i = 0; > > I just don't like casts, they suggest the underlying types are wrong, > so should fix that, not add a cast. This particular one is absolutely fine. When you want to multiply u32 by u32, you always need a cast, otherwise the result will be truncated. mul_u32_u32() does it the very same way[0]. > > Andrew > [0] https://elixir.bootlin.com/linux/v6.1-rc6/source/include/linux/math64.h#L153 Thanks, Olek
On Mon, 21 Nov 2022 10:56:18 +0300 Maxim Korotkov wrote: > Found by Linux Verification Center (linuxtesting.org) with SVACE. > > Fixes: 2adc6edcaec0 ("ethtool: fix error handling in ethtool_phys_id") I'm leaning towards dropping the fixes tag, and applying to -next. Drivers returning high enough rc to cause an overflow seems theoretical, and is pretty harmless. Please LMK if I'm missing something.
> -----Original Message----- > From: Alexander Lobakin <alexandr.lobakin@intel.com> > Sent: Monday, November 21, 2022 7:03 AM > To: Andrew Lunn <andrew@lunn.ch> > Cc: Lobakin, Alexandr <alexandr.lobakin@intel.com>; Maxim Korotkov > <korotkov.maxim.s@gmail.com>; David S. Miller <davem@davemloft.net>; Eric > Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo > Abeni <pabeni@redhat.com>; Guangbin Huang > <huangguangbin2@huawei.com>; Tom Rix <trix@redhat.com>; Marco Bonelli > <marco@mebeim.net>; Edward Cree <ecree@solarflare.com>; > netdev@vger.kernel.org; linux-kernel@vger.kernel.org; lvc- > project@linuxtesting.org > Subject: Re: [PATCH] ethtool: avoiding integer overflow in ethtool_phys_id() > > From: Andrew Lunn <andrew@lunn.ch> > Date: Mon, 21 Nov 2022 15:10:18 +0100 > > > On Mon, Nov 21, 2022 at 10:56:18AM +0300, Maxim Korotkov wrote: > > > The value of an arithmetic expression "n * id.data" is subject > > > to possible overflow due to a failure to cast operands to a larger data > > > type before performing arithmetic. Added cast of first operand to u64 > > > for avoiding overflow. > > > > > > Found by Linux Verification Center (linuxtesting.org) with SVACE. > > > > > > Fixes: 2adc6edcaec0 ("ethtool: fix error handling in ethtool_phys_id") > > > Signed-off-by: Maxim Korotkov <korotkov.maxim.s@gmail.com> > > > --- > > > net/ethtool/ioctl.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c > > > index 6a7308de192d..cf87e53c2e74 100644 > > > --- a/net/ethtool/ioctl.c > > > +++ b/net/ethtool/ioctl.c > > > @@ -2007,7 +2007,7 @@ static int ethtool_phys_id(struct net_device *dev, > void __user *useraddr) > > > } else { > > > /* Driver expects to be called at twice the frequency in rc */ > > > int n = rc * 2, interval = HZ / n; > > > - u64 count = n * id.data, i = 0; > > > + u64 count = (u64)n * id.data, i = 0; > > > > > > How about moving the code around a bit, change n to a u64 and drop the > > cast? Does this look correct? > > > > int interval = HZ / rc / 2; > > u64 n = rc * 2; > > u64 count = n * id.data; > > > > i = 0; > > > > I just don't like casts, they suggest the underlying types are wrong, > > so should fix that, not add a cast. > > This particular one is absolutely fine. When you want to multiply > u32 by u32, you always need a cast, otherwise the result will be > truncated. mul_u32_u32() does it the very same way[0]. > Why not just use mul_u32_u32 then? Thanks, Jake > > > > Andrew > > > > [0] https://elixir.bootlin.com/linux/v6.1- > rc6/source/include/linux/math64.h#L153 > > Thanks, > Olek
Ok, I'll replace cast to macro in patch V2 On 22.11.2022 00:30, Keller, Jacob E wrote: > > >> -----Original Message----- >> From: Alexander Lobakin <alexandr.lobakin@intel.com> >> Sent: Monday, November 21, 2022 7:03 AM >> To: Andrew Lunn <andrew@lunn.ch> >> Cc: Lobakin, Alexandr <alexandr.lobakin@intel.com>; Maxim Korotkov >> <korotkov.maxim.s@gmail.com>; David S. Miller <davem@davemloft.net>; Eric >> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo >> Abeni <pabeni@redhat.com>; Guangbin Huang >> <huangguangbin2@huawei.com>; Tom Rix <trix@redhat.com>; Marco Bonelli >> <marco@mebeim.net>; Edward Cree <ecree@solarflare.com>; >> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; lvc- >> project@linuxtesting.org >> Subject: Re: [PATCH] ethtool: avoiding integer overflow in ethtool_phys_id() >> >> From: Andrew Lunn <andrew@lunn.ch> >> Date: Mon, 21 Nov 2022 15:10:18 +0100 >> >>> On Mon, Nov 21, 2022 at 10:56:18AM +0300, Maxim Korotkov wrote: >>>> The value of an arithmetic expression "n * id.data" is subject >>>> to possible overflow due to a failure to cast operands to a larger data >>>> type before performing arithmetic. Added cast of first operand to u64 >>>> for avoiding overflow. >>>> >>>> Found by Linux Verification Center (linuxtesting.org) with SVACE. >>>> >>>> Fixes: 2adc6edcaec0 ("ethtool: fix error handling in ethtool_phys_id") >>>> Signed-off-by: Maxim Korotkov <korotkov.maxim.s@gmail.com> >>>> --- >>>> net/ethtool/ioctl.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c >>>> index 6a7308de192d..cf87e53c2e74 100644 >>>> --- a/net/ethtool/ioctl.c >>>> +++ b/net/ethtool/ioctl.c >>>> @@ -2007,7 +2007,7 @@ static int ethtool_phys_id(struct net_device *dev, >> void __user *useraddr) >>>> } else { >>>> /* Driver expects to be called at twice the frequency in rc */ >>>> int n = rc * 2, interval = HZ / n; >>>> - u64 count = n * id.data, i = 0; >>>> + u64 count = (u64)n * id.data, i = 0; >>> >>> >>> How about moving the code around a bit, change n to a u64 and drop the >>> cast? Does this look correct? >>> >>> int interval = HZ / rc / 2; >>> u64 n = rc * 2; >>> u64 count = n * id.data; >>> >>> i = 0; >>> >>> I just don't like casts, they suggest the underlying types are wrong, >>> so should fix that, not add a cast. >> >> This particular one is absolutely fine. When you want to multiply >> u32 by u32, you always need a cast, otherwise the result will be >> truncated. mul_u32_u32() does it the very same way[0]. >> > > Why not just use mul_u32_u32 then? > > Thanks, > Jake > >>> >>> Andrew >>> >> >> [0] https://elixir.bootlin.com/linux/v6.1- >> rc6/source/include/linux/math64.h#L153 >> >> Thanks, >> Olek
diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c index 6a7308de192d..cf87e53c2e74 100644 --- a/net/ethtool/ioctl.c +++ b/net/ethtool/ioctl.c @@ -2007,7 +2007,7 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr) } else { /* Driver expects to be called at twice the frequency in rc */ int n = rc * 2, interval = HZ / n; - u64 count = n * id.data, i = 0; + u64 count = (u64)n * id.data, i = 0; do { rtnl_lock();