Message ID | 20230323103735.2331786-1-a.fatoum@pengutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp2836343wrt; Thu, 23 Mar 2023 03:50:22 -0700 (PDT) X-Google-Smtp-Source: AK7set+NFcrp5W1SMkBgstDU3fexrm1URRcnlguSq9sXBLJSrVvqxHKDu5G5wiiurm01EvcAM7Qj X-Received: by 2002:a17:902:f544:b0:1a1:b8cc:59da with SMTP id h4-20020a170902f54400b001a1b8cc59damr7238323plf.33.1679568622279; Thu, 23 Mar 2023 03:50:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679568622; cv=none; d=google.com; s=arc-20160816; b=h1EXj/F5hfTZ3yog6pRjZjkJ6+2rAQJ8i4bckXJn8I4sCvk9HRNxRZnQ8k9KJub3eX uXEdAhZ0G/q+k5S00PS6WN3mBjyO0g9CHYOTeqR04h79+sOIeJVCJHbjqAUg9YD5keVc f4dxr2XYVMUtHi7MZ331307Kriu/gXBMwwqF+oIkIIyMFPtgpeVb0y5b91yF5RNjmGbA U1bQGhGxVPNHbEolCoLTXkXHpSnM18ZlcvmONN7eu9VdNPqbaYDuXenacVShJzBWREoS C1r9VuolPFUjvBaVrWJBQV404O4/oHuTFbrkCpMOtNj7mtx95qcvMJWRjC/RbfX2ZyXP Rk/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=NMxxQ0kKlxa+asOANAbeo9krXbJbYFeXVhp+7liv2fM=; b=Xwgz8jijHywblJAPEnv5Oj7IY6gZ75zJq00yRfuFepHi1UP6b3yAxRGOdKXMxS7nii yuMiPrkdfZyyHdBY2FCM/Y60K3LYlye9h1mCDnc3YSMkok7y5G5Qy/o+XQ7CbFSPm0yD jsXrHvQHzCqzeL9VITAM6FZ3cCkpHB/q95j0bETl6Xj+RWYcEzpn690yM7ChlGHsni/U vuv8LYT9CVFgXLLZTA4zhLrPDYh2ppEZ7R883YDPWgZacwPL4Imf8jt1FOraLWY++iK7 Fx4HKtoolHTzHoSjRcM+/W0ECYvS3Oif6RmcB627ZHNc2bem80BwFEYrI3NTLY7vpRTw U/AA== ARC-Authentication-Results: i=1; mx.google.com; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a9-20020a170902ecc900b001a05a78f952si19851887plh.272.2023.03.23.03.50.08; Thu, 23 Mar 2023 03:50:22 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229589AbjCWKlA (ORCPT <rfc822;ezelljr.billy@gmail.com> + 99 others); Thu, 23 Mar 2023 06:41:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229990AbjCWKkg (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 23 Mar 2023 06:40:36 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 030241C311 for <linux-kernel@vger.kernel.org>; Thu, 23 Mar 2023 03:37:51 -0700 (PDT) Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <afa@pengutronix.de>) id 1pfIKD-0006Dh-SD; Thu, 23 Mar 2023 11:37:41 +0100 Received: from [2a0a:edc0:0:1101:1d::54] (helo=dude05.red.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtp (Exim 4.94.2) (envelope-from <afa@pengutronix.de>) id 1pfIKB-00680F-3n; Thu, 23 Mar 2023 11:37:39 +0100 Received: from afa by dude05.red.stw.pengutronix.de with local (Exim 4.94.2) (envelope-from <afa@pengutronix.de>) id 1pfIK9-009wtp-V6; Thu, 23 Mar 2023 11:37:37 +0100 From: Ahmad Fatoum <a.fatoum@pengutronix.de> To: Linus Walleij <linus.walleij@linaro.org>, =?utf-8?q?Alvin_=C5=A0ipraga?= <alsi@bang-olufsen.dk>, Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>, Vladimir Oltean <olteanv@gmail.com>, Luiz Angelo Daros de Luca <luizluca@gmail.com>, "David S. Miller" <davem@davemloft.net> Cc: kernel@pengutronix.de, Ahmad Fatoum <a.fatoum@pengutronix.de>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net v2] net: dsa: realtek: fix out-of-bounds access Date: Thu, 23 Mar 2023 11:37:35 +0100 Message-Id: <20230323103735.2331786-1-a.fatoum@pengutronix.de> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: afa@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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?1761155347653867842?= X-GMAIL-MSGID: =?utf-8?q?1761155347653867842?= |
Series |
[net,v2] net: dsa: realtek: fix out-of-bounds access
|
|
Commit Message
Ahmad Fatoum
March 23, 2023, 10:37 a.m. UTC
The probe function sets priv->chip_data to (void *)priv + sizeof(*priv) with the expectation that priv has enough trailing space. However, only realtek-smi actually allocated this chip_data space. Do likewise in realtek-mdio to fix out-of-bounds accesses. These accesses likely went unnoticed so far, because of an (unused) buf[4096] member in struct realtek_priv, which caused kmalloc to round up the allocated buffer to a big enough size, so nothing of value was overwritten. With a different allocator (like in the barebox bootloader port of the driver) or with KASAN, the memory corruption becomes quickly apparent. Fixes: aac94001067d ("net: dsa: realtek: add new mdio interface for drivers") Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> --- v1 -> v2: - drop v1's patch 2/2, which appears to have no functional effect (Jakub) - extend commit message with probable reason why this long standing bug did not pop up so far in Linux (Prompted by Linus' question) - use saturating size_add instead of wrap-around addition (Jakub) - added reviewer R-b's --- drivers/net/dsa/realtek/realtek-mdio.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
Comments
Hello: This patch was applied to netdev/net.git (main) by Jakub Kicinski <kuba@kernel.org>: On Thu, 23 Mar 2023 11:37:35 +0100 you wrote: > The probe function sets priv->chip_data to (void *)priv + sizeof(*priv) > with the expectation that priv has enough trailing space. > > However, only realtek-smi actually allocated this chip_data space. > Do likewise in realtek-mdio to fix out-of-bounds accesses. > > These accesses likely went unnoticed so far, because of an (unused) > buf[4096] member in struct realtek_priv, which caused kmalloc to > round up the allocated buffer to a big enough size, so nothing of > value was overwritten. With a different allocator (like in the barebox > bootloader port of the driver) or with KASAN, the memory corruption > becomes quickly apparent. > > [...] Here is the summary with links: - [net,v2] net: dsa: realtek: fix out-of-bounds access https://git.kernel.org/netdev/net/c/b93eb5648693 You are awesome, thank you!
diff --git a/drivers/net/dsa/realtek/realtek-mdio.c b/drivers/net/dsa/realtek/realtek-mdio.c index 7134886fe78d..1691faf77f00 100644 --- a/drivers/net/dsa/realtek/realtek-mdio.c +++ b/drivers/net/dsa/realtek/realtek-mdio.c @@ -21,6 +21,7 @@ #include <linux/module.h> #include <linux/of_device.h> +#include <linux/overflow.h> #include <linux/regmap.h> #include "realtek.h" @@ -152,7 +153,9 @@ static int realtek_mdio_probe(struct mdio_device *mdiodev) if (!var) return -EINVAL; - priv = devm_kzalloc(&mdiodev->dev, sizeof(*priv), GFP_KERNEL); + priv = devm_kzalloc(&mdiodev->dev, + size_add(sizeof(*priv), var->chip_data_sz), + GFP_KERNEL); if (!priv) return -ENOMEM;