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 EE7FBC3601E for ; Mon, 14 Apr 2025 06:57:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=qgIGZtbyDWNdLENvjzYEYqeo+MEdxCqSLe4QrssoM+Q=; b=4YU56xKC3TTwJIO1Ol7zFOuTlG uq+e4lsnaa2Sa+hqSfl7iwtdSPGIprlTdJSpiZhq+0xb5FPke2gSmBVmgy7kAI6u/6Rf06B3Ia1qD 3zZ8/Hd1TdlOiGDo866ww2F6B0MesqxEMMMXGXsXcPzOwANU40gD9LFzgq2UMHH9w+kFjat0DhaIN QZUBaz1VEnnfVFm8UelfCgPmA4MCPvRjxTkFxgwlBIvR1uOQGuN+O3QSaOsnUDdR1zt3xn2YgXJYv lt2uJDmtNy9qINmxwOMHdd9Y00alkXms+ykIunenmfm2g6tcOSyG3l5FLfYENl4VUJVJ2QA5CPUhJ 1OAMWlsA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1u4Dl8-00000000rbc-2DTo; Mon, 14 Apr 2025 06:57:34 +0000 Received: from nyc.source.kernel.org ([147.75.193.91]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1u4Ddq-00000000qh3-2i9S for linux-arm-kernel@lists.infradead.org; Mon, 14 Apr 2025 06:50:03 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 56119A484D8; Mon, 14 Apr 2025 06:44:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67A15C4CEEA; Mon, 14 Apr 2025 06:50:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744613401; bh=Zb2I1FUbMuXCq7QyHRV4fVv0cmMyEywk1cCMFB34KMM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=erMfOtTWMNwwMWVFEc+ag6/7Qr80cI33yV2vA09xsbScoKBQT6P3CooCHbwSLE+5n lKMM1jcQdXkeMRWAqArSCTMSN9H9E5cO1ouDD2Nu6FZS/S89tU/sU7aXdJoDvlAACG lCMsYrCrRGXvgha2BZgVeU4o+5sS9WciVoAuxBeBzA0rwMOoTb2+9PNgzbvo7eKOcg mYTfNvrjYQR2ImpoT6jqXKsSUUtwaEZ34/giU3LW6SV2O9OY7gYnHAR0cHAqIfyy0K X0Du7pz7K7O+Udwy28Htm1RlD+74bMhebPOe4UKn+zCaYSMn4bbwpsybPCtxoS2xuL sbtZoDugi2zuw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1u4Ddm-00583T-PR; Mon, 14 Apr 2025 07:49:58 +0100 Date: Mon, 14 Apr 2025 07:49:58 +0100 Message-ID: <868qo3kzjd.wl-maz@kernel.org> From: Marc Zyngier To: Chenyuan Yang Cc: sven@svenpeter.dev, j@jannau.net, alyssa@rosenzweig.io, neal@gompa.dev, rafael@kernel.org, viresh.kumar@linaro.org, marcan@marcan.st, asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] cpufreq: apple-soc: Fix possible null pointer dereference In-Reply-To: References: <20250412160518.1824538-1-chenyuan0y@gmail.com> <86bjt0l6q4.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: chenyuan0y@gmail.com, sven@svenpeter.dev, j@jannau.net, alyssa@rosenzweig.io, neal@gompa.dev, rafael@kernel.org, viresh.kumar@linaro.org, marcan@marcan.st, asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250413_235002_832685_C1DD650D X-CRM114-Status: GOOD ( 30.33 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, 13 Apr 2025 22:31:26 +0100, Chenyuan Yang wrote: >=20 > On Sun, Apr 13, 2025 at 5:02=E2=80=AFAM Marc Zyngier wro= te: > > > > On Sat, 12 Apr 2025 17:05:18 +0100, > > Chenyuan Yang wrote: > > > > > > Check if policy is NULL before dereferencing it. > > > > > > This is similar to the commit cf7de25878a1 > > > ("cppc_cpufreq: Fix possible null pointer dereference"). > > > > > > > No, it's not similar. The patch you refer to actually introduces bugs > > by returning -ENODEV in functions that have an unsigned return type. > > > > > This is found by our static analysis tool KNighter. > > > > I'm surprised that your tool hasn't found the above, because it should > > be a pretty easy thing to do. > > > > Irrespective of this, it would be good to describe under which > > circumstances this can occur, because I can't see *how* this can > > trigger. The policy is directly provided by the core code and provide > > its association with a cpu, and is never NULL at the point of init. >=20 > Our tool currently identifies bug patterns by analyzing patches. For > example, in the similar function cppc_cpufreq_get_rate(), > a patch was applied to add a null check for the policy. Therefore, we > assume that a similar check should be implemented here That's not static analysis, that's just an evolved form of pseudo-AI driven copy/paste patching. In other words, the worst sort of tool. >=20 > > And if it can trigger, why only fix this one particular case? > > Dereferences of policy are all over the map, and would be just as > > wrong. >=20 > It appears that similar checks are implemented in other areas=E2=80=94suc= h as > in acpi-cpufreq.c, cppc_cpufreq.c, drivers/cpufreq/cpufreq_ondemand.c, > and drivers/cpufreq/cpufreq.c. > However, I'm not sure if apple_soc should adopt the same checking style. I don't think adding more crap without proper justification is the way to go. If this value can be NULL, you should be able to demonstrate an execution that leads to this behaviour. That's what an analysis tool would perform. M. --=20 Without deviation from the norm, progress is not possible.