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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 78595C6FD1F for ; Wed, 20 Mar 2024 19:47:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=D3UEBH+vGCOaeH4GI3cbQXd5Q8mIoVFj9/Hw3c1oi+Q=; b=CNsOeyGQWc+Spd QBrx4fpxlbTZMg56GDIog0I6nGUmWwPatiSuXOD+p1ZudB9am4YBd2zQjesTQFH69u6nqKXJ6EWa1 YFXBbVgIPpF/xgySXuXGDuei/cgCiWJX/XmbakL3WDKU/uVk3MbQs+febYOKjln7+QBcER1GJ6u3p 4nVlI25Luo9RDLVYFCZ9sK/JfRxYubtagCSGaQas7VzbeQqWA/7Jdm8Hqv2FWQDh2H0es6kV3oAYE rHbKISwuR7Hj9myE2QiqzKmHiMqHibrPzYLvJAntKAQNmmb+Qt2HUhs0pque/OvePwzfOBLtzzL2F OhZzpAq1wKMY8CnW5dqg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rn1ti-00000000ogd-2725; Wed, 20 Mar 2024 19:46:50 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rn1tf-00000000ofy-3ESM for linux-arm-kernel@lists.infradead.org; Wed, 20 Mar 2024 19:46:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dRUcwh/Yv+4zp77r583PpSlVkysLgJagM5Xelbk0AIE=; b=Jt/J+Hic+3aXQ7DPjpjWwRv2Zu /3C/F6p7xHevPYi0COax9B5+hABR0AzmYFIBRefJsGuQfUFFdBrvCmYT9vf+tXfLqEL+gX/Zjv7gB n6s1bAMTz6quaUdJPjvY1GKgmD7WcvplzoQmbgnv9DK3r05brc5N9xg2QpZdiRms4nSXtpFoqF1Cx UbgltYybbmpIGre9jh2RuYSf517k7vAPTVCy3FMIrGorjQhwcRvVHcH/WST2eE314TeJirCQ7II6h rY4nxmXYnRB0zV3kdkg/s2ujOPVw1CGgKYe6es9fuNo9I7e+41zwhCr0fFS0Kiatj/t0Pk3quh294 poT6mt4Q==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:59392) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rn1tb-0006rE-2a; Wed, 20 Mar 2024 19:46:43 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1rn1tb-0002wJ-NA; Wed, 20 Mar 2024 19:46:43 +0000 Date: Wed, 20 Mar 2024 19:46:43 +0000 From: "Russell King (Oracle)" To: zzjas98@gmail.com Cc: Andrew Lunn , gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com, linux-arm-kernel@lists.infradead.org, chenyuan0y@gmail.com Subject: Re: [arch/arm/mach-mvebu] Question about kzalloc NULL check in i2c_quirk Message-ID: References: <1e40d5f4-72ac-40ca-8fb0-34884e7ac549@gmail.com> <2baa9e59-fe81-4c92-b6ca-a86233c5e06d@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <2baa9e59-fe81-4c92-b6ca-a86233c5e06d@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240320_124647_837103_577FC7C4 X-CRM114-Status: GOOD ( 24.95 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Wed, Mar 20, 2024 at 01:48:26PM -0500, zzjas98@gmail.com wrote: > On 3/20/24 7:27 AM, Andrew Lunn wrote: > > On Tue, Mar 19, 2024 at 10:03:22PM -0500, Zijie Zhao wrote: > > > Dear ARM/Marvell maintainers, > > > > > > We came across an unusual usage of kzalloc in > > > arch/arm/mach-mvebu/board-v7.c, function i2c_quirk: > > > > > > https://elixir.bootlin.com/linux/v6.8/source/arch/arm/mach-mvebu/board-v7.c#L127 > > > ``` > > > static void __init i2c_quirk(void) > > > { > > > struct device_node *np; > > > u32 dev, rev; > > > > > > /* > > > * Only revisons more recent than A0 support the offload > > > * mechanism. We can exit only if we are sure that we can > > > * get the SoC revision and it is more recent than A0. > > > */ > > > if (mvebu_get_soc_id(&dev, &rev) == 0 && rev > MV78XX0_A0_REV) > > > return; > > > > > > for_each_compatible_node(np, NULL, "marvell,mv78230-i2c") { > > > struct property *new_compat; > > > > > > new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL); > > > > > > new_compat->name = kstrdup("compatible", GFP_KERNEL); > > > new_compat->length = sizeof("marvell,mv78230-a0-i2c"); > > > new_compat->value = kstrdup("marvell,mv78230-a0-i2c", > > > GFP_KERNEL); > > > > > > of_update_property(np, new_compat); > > > } > > > } > > > ``` > > > > > > Should the new_compat be checked against NULL in case kzalloc fails, to > > > avoid NULL dereference later in the code? > > > > > > Please kindly let us know if we missed any key information and this is > > > actually intended. We appreciate your information and time! Thanks! > > > > What context is this code run in? What would need to happen for the > > allocation to fail? And what happens next if it does fail, both in > > this function and the system in general? > > > > Andrew > > > > Hi Andrew, > > Thanks for checking! > > We encountered this kzalloc while doing a static analysis for the kernel code. > > kzalloc would return NULL in case of out-of-memory and would make the next field access new_compat->name segfault. If we are out of memory at this point in the kernel boot, then what are the chances of the kernel getting to the point where it can run userspace? I think that is the essence of Andrew's argument. A failure to allocate memory here means there is a serious problem and the system won't boot _even_ if we add something like: if (!new_compat) continue; to that loop. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel