From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0EA2C63697 for ; Tue, 17 Nov 2020 23:26:07 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 67B88208B8 for ; Tue, 17 Nov 2020 23:26:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="kN5NR7mm"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ti.com header.i=@ti.com header.b="FSwxrQQQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67B88208B8 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=ti.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=gbhqBqZ/urZDSfZzWXNqC9BVvsgBDKDM7ERfqGGcAlk=; b=kN5NR7mmoa5tVKtdjHEFLsEPA TrA/XuIEowdIpaWKsDxC+bymCpoqmDF7nIZ8ijX4U37rz9v+eJYspeHN+p6wdGPYLd0G31nkylqL7 baDP492QYVedKFOX/dlqpgCheaOm0JmCqaJnQARQ2sawlSdtYNr3dS7rbAR5IjD537Sw4+2JjuQFc BJ8Xs9pkcUk6BqJNsZaFwOX2XIcVL+lhGTfj4cD9sy+omVxJiUiVSAL4Smg1lqi3hAB9midebjMXD ySEcp8v3sNpbSK9wMFEIPMkbiSNl/6hdhx3no11dYltyJkVro6E5V58ZnlxsqYEUXn3n+rx59N6kM 8Mj0KCgWg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfALA-0000qx-Ak; Tue, 17 Nov 2020 23:24:48 +0000 Received: from fllv0015.ext.ti.com ([198.47.19.141]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfAL5-0000nj-FB for linux-arm-kernel@lists.infradead.org; Tue, 17 Nov 2020 23:24:46 +0000 Received: from fllv0035.itg.ti.com ([10.64.41.0]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 0AHNO712032017; Tue, 17 Nov 2020 17:24:07 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1605655447; bh=BPjxYG10nNEarUm95nLoroA2ShGvg7pn52uDyKMVgAk=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=FSwxrQQQRtLBvw28CJ46qgx188WRV3MOSiS8tPYqf5tP7nzTgVkVVR2J+XabXPsFi UZkGBZR6rnQcrAdtR64jgBMqWm4yccPbSr5txNDhSq2dp1jQ48P/VZe3av13KXWHTV le/fM99rJgr6CGgztSZlgEDHkaq1qra7IYBpRBxI= Received: from DFLE104.ent.ti.com (dfle104.ent.ti.com [10.64.6.25]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 0AHNO7hi097004 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 17 Nov 2020 17:24:07 -0600 Received: from DFLE112.ent.ti.com (10.64.6.33) by DFLE104.ent.ti.com (10.64.6.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Tue, 17 Nov 2020 17:24:06 -0600 Received: from fllv0039.itg.ti.com (10.64.41.19) by DFLE112.ent.ti.com (10.64.6.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Tue, 17 Nov 2020 17:24:06 -0600 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 0AHNO6Am130347; Tue, 17 Nov 2020 17:24:06 -0600 Date: Tue, 17 Nov 2020 17:24:06 -0600 From: Nishanth Menon To: Arnd Bergmann Subject: Re: [arm] BUG: KASAN: slab-out-of-bounds in memcmp+0x30/0x5c Message-ID: <20201117232343.rg37fkacw43matmh@revered> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201117_182443_645978_E30FD500 X-CRM114-Status: GOOD ( 34.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ulf Hansson , Arnd Bergmann , Naresh Kamboju , linux-mmc , open list , lkft-triage@lists.linaro.org, Liam Girdwood , linux-mm , Linux-Next Mailing List , Mark Brown , Steven Rostedt , Andrew Morton , Linux-OMAP , Linus Walleij , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 16:25-20201117, Arnd Bergmann wrote: > On Tue, Nov 17, 2020 at 3:44 PM Naresh Kamboju > wrote: > > > > While booting arm KASAN config enabled kernel on TI x15 device > > Linux version 5.10.0-rc3-next-20201116. > > > > The reported issue is not a regression since we have recently started testing > > arm+kasan builds on LKFT. > > > > The boot was not successful on x15 and qemu_arm for some other reason. > > The kernel config and crash log attached to this email. > > Nice find! > > > [ 13.071906] BUG: KASAN: slab-out-of-bounds in memcmp+0x30/0x5c > > [ 13.077526] Synopsys Designware Multimedia Card Interface Driver > > [ 13.077781] Read of size 1 at addr c5ae1d90 by task kworker/0:0/5 > > [ 13.089918] > > [ 13.091433] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted > > 5.10.0-rc3-next-20201116 #2 > > [ 13.093605] sdhci-pltfm: SDHCI platform and OF driver helper > > [ 13.099135] Hardware name: Generic DRA74X (Flattened Device Tree) > > [ 13.110942] Workqueue: events dbs_work_handler > > [ 13.115442] [] (unwind_backtrace) from [] > > (show_stack+0x10/0x14) > > [ 13.123240] [] (show_stack) from [] > > (dump_stack+0xc8/0xe0) > > [ 13.130518] [] (dump_stack) from [] > > (print_address_description.constprop.0+0x34/0x2dc) > > [ 13.140238] [] (print_address_description.constprop.0) > > from [] (kasan_report+0x1a8/0x1c4) > > [ 13.145871] omap_gpio 4805d000.gpio: Could not set line 27 debounce > > to 200000 microseconds (-22) > > [ 13.150221] [] (kasan_report) from [] (memcmp+0x30/0x5c) > > [ 13.159064] sdhci-omap 4809c000.mmc: Got CD GPIO > > [ 13.166123] [] (memcmp) from [] > > (ti_abb_set_voltage_sel+0x94/0x58c) > > [ 13.166150] [] (ti_abb_set_voltage_sel) from [] > > (_regulator_call_set_voltage_sel+0xd8/0x12c) > > > I see this code in ti_abb_set_voltage_sel(): > > if (sel >= desc->n_voltages) { > dev_err(dev, "%s: sel idx(%d) >= n_voltages(%d)\n", __func__, > sel, desc->n_voltages); > return -EINVAL; > } > > /* If we are in the same index as we were, nothing to do here! */ > if (sel == abb->current_info_idx) { > dev_dbg(dev, "%s: Already at sel=%d\n", __func__, sel); > return ret; > } > > /* If data is exactly the same, then just update index, no change */ > info = &abb->info[sel]; > oinfo = &abb->info[abb->current_info_idx]; > if (!memcmp(info, oinfo, sizeof(*info))) { > > One of the two pointers overflows the abb->info array that is allocated > with length 'desc->n_voltages'. The 'sel' argument is checked against > that limit, so I assume it's abb->current_info_idx, and this is indeed > initialized as > > /* We do not know where the OPP voltage is at the moment */ > abb->current_info_idx = -EINVAL; > > Using the negative '-EINVAL' as an array index would indeed cause > an out-of-bounds access. > > Could you try adding this extra bounds check? > > index 3e60bff76194..c475a9461027 100644 > --- a/drivers/regulator/ti-abb-regulator.c > +++ b/drivers/regulator/ti-abb-regulator.c > @@ -345,7 +345,8 @@ static int ti_abb_set_voltage_sel(struct > regulator_dev *rdev, unsigned sel) > /* If data is exactly the same, then just update index, no change */ > info = &abb->info[sel]; > oinfo = &abb->info[abb->current_info_idx]; > - if (!memcmp(info, oinfo, sizeof(*info))) { > + if (abb->current_info_idx >= 0 && > + !memcmp(info, oinfo, sizeof(*info))) { > dev_dbg(dev, "%s: Same data new idx=%d, old idx=%d\n", __func__, > sel, abb->current_info_idx); > goto out; > > Arnd Yes, this was indeed a bug that has been around for some time now :( I tested with a variant of the above (did'nt like that oinfo was being assigned an invalid address) Boot log: https://pastebin.ubuntu.com/p/nZfz3HF8N6/ (with the same config as in the report): Would you prefer to me to send the following as a formal patch? diff --git a/drivers/regulator/ti-abb-regulator.c b/drivers/regulator/ti-abb-regulator.c index 3e60bff76194..9f0a4d50cead 100644 --- a/drivers/regulator/ti-abb-regulator.c +++ b/drivers/regulator/ti-abb-regulator.c @@ -342,8 +342,17 @@ static int ti_abb_set_voltage_sel(struct regulator_dev *rdev, unsigned sel) return ret; } - /* If data is exactly the same, then just update index, no change */ info = &abb->info[sel]; + /* + * When Linux kernel is starting up, we are'nt sure of the + * Bias configuration that bootloader has configured. + * So, we get to know the actual setting the first time + * we are asked to transition. + */ + if (abb->current_info_idx == -EINVAL) + goto just_set_abb; + + /* If data is exactly the same, then just update index, no change */ oinfo = &abb->info[abb->current_info_idx]; if (!memcmp(info, oinfo, sizeof(*info))) { dev_dbg(dev, "%s: Same data new idx=%d, old idx=%d\n", __func__, @@ -351,6 +360,7 @@ static int ti_abb_set_voltage_sel(struct regulator_dev *rdev, unsigned sel) goto out; } +just_set_abb: ret = ti_abb_set_opp(rdev, abb, info); out: -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel