From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f182.google.com (mail-dy1-f182.google.com [74.125.82.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BFB4B30595B for ; Wed, 27 May 2026 01:41:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779846099; cv=none; b=PssnHEfGgdGzQryPrbXA8LFPbXOtHzUMuraBsVnSQvoe84T79M2/FCW5lZmsAj5lUeXwNaaDYXvvOrxd4kkiWvuVc23aH43Rdw2Z/p4PmOYvgFix2Jef7i9Huwe4rZ8ZCJw2DKBvY0vd7KsfefnrKcuXukPOUzUlTDkt0jWmr5w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779846099; c=relaxed/simple; bh=PwQS2roM7u1JRs8URNYjYhAgeauNxT5Yc1Lwb5UnGqM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Pt6j5azb+gt2M/C9+yOshW9tcIRShhcVqP6YnUs926V0+jYdrySlVrFMOenPZRFZolNpW7UxL+wqrSIW0cb4U7YRRgkRmmk2Vs7qMp5gtLqJ5OVv8A2LUATsUtIz22VMofWg/I/WKE59f1F2W5yHxE6uKKDZZ3acaZtXIB0xIGQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=k8H3h/0b; arc=none smtp.client-ip=74.125.82.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="k8H3h/0b" Received: by mail-dy1-f182.google.com with SMTP id 5a478bee46e88-2ee990e8597so26612759eec.1 for ; Tue, 26 May 2026 18:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779846097; x=1780450897; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=uN5DfBzCdxgMtcbb6Yn1Crv8Mos2ktrmL1d0GO1AHx0=; b=k8H3h/0bfePOVCAqhgOz/KhJvHNlS07CBaB2t5Z7deGHy7PS7YAMEIpDiAl1mkmdZn CBDFE+PXTabHtacTVscpaVfmFXf0BVS9tJk9MNbJEmzGpPUhsxffcrzTxovHVctaSjAJ Blfz1pXVNQtsWiWat0sPgQtR8SkcamdEg2s4cnrynvDAy0wUehJAOshsbp5UnbKGutIg tbdKerZNSa1LII0A8TusPeLCGPAqls5n8i59hNq16Lo95mRJ4e3kwZL8SmiABgGEZY1M 6HV8OSLvckEVZEnaAqCknSSrcE1TyuVBFYnQ/GHCTWrhjaQ2GU3BVf0AUQJCv9RPYjLT bvzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779846097; x=1780450897; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uN5DfBzCdxgMtcbb6Yn1Crv8Mos2ktrmL1d0GO1AHx0=; b=or51FGAEqO3Hz/wenZTtPTKSLS6kyuyc+WDzUdYqXp/KtEUh4XDBgE+pC/cDSfXF7n 5I+1uQ75VOu6Xa0oKlBnT+gyUDFLUfsDsBm/SXQsG6mJxmoZauTFQoPVQ93drsNXZlqp 56TwxAiWp2nS9Lp1c6FGIxATvB2+x+rqTn+PmK3z9bR5IvHx+1f1dfCT4N+4ZwVLrXbS xuIdv+wj1AHrUJZmNi1DcjsHRyyEUy7FxqLzrh/lXPGiyn9AMt4SyfWaP8qOObQ1RTIz HlJz3dHMkSe+zsbY47hGNq4jXY4sz3ruPLpOX8rEMI7HElOfdb2ODmlNOZ6rQqrPkYBg auzg== X-Forwarded-Encrypted: i=1; AFNElJ+7pl3yMr/1yOo2qJEaSXYBHpTZB/vSWe5W8SUCHjNVYvLYfsYHqXNNuMCBvkOMEpGvthXTZggplr+IA34=@vger.kernel.org X-Gm-Message-State: AOJu0Yy58elJdKmMxm6rtgQkzKr12rjidYbaX5MPu6bS2BwD5M5PnSKL 1ZzJQdrrYor4pAIGtCPIrjwxEvPgmkO6KG1l4WRsTdo9SfR3kGtTH0iF X-Gm-Gg: Acq92OGW8GfIG7FnWqQd7JYHXJ1LcQcbtPBO1t5NmIDISBnFvWjdseywnpBJnqHOw2i BvUL55HsgNrBX8vCKrY0qbbDtHhOjrKguFR0wAj+kAspIpFsm4/ksS6Di2Rp1VcORXPaxZDYqjf HLuFb/OO6TR9M618AO//OcFYD2HioX1rUevb7NJK+57ENeajwDxCfy26bf3N9QyMg35uVB487Hl EuuqgaWddktBzQPUWsRw23+Shi0QMF9bej8u5Gd2PCw9UMwnEmpTtNsxpeNIIRat/GNcQQz6cQt FX7TLedDh05G1effJJpytbquHFUrwHvi6pUPiUeQhJ7Nlv7g/qAXbY/6BBcZb4lItFpMEsfoV2Y FIRAcT37uqAFiD3r/LfBPfW0nWTmCS7M0LUC2uplcRSwyX2uutKEhunXlGir7BVJiKnUWGXHeAR QuH4fL1Hca/VVf/arPUSGiJZKZQgRAYTre+2NmLUQu1m+DuceQ610uXGv73LwSPdBgrRX4k+3Gv x4= X-Received: by 2002:a05:7300:4305:b0:2ef:1d11:18ae with SMTP id 5a478bee46e88-3044912c25amr9993942eec.28.1779846096801; Tue, 26 May 2026 18:41:36 -0700 (PDT) Received: from google.com ([2a00:79e0:2ebe:8:912f:eb49:d713:7401]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-304a57c04f8sm3258965eec.11.2026.05.26.18.41.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2026 18:41:36 -0700 (PDT) Date: Tue, 26 May 2026 18:41:33 -0700 From: Dmitry Torokhov To: Rosen Penev Cc: linux-input@vger.kernel.org, Matthias Brugger , AngeloGioacchino Del Regno , "open list:ARM/Mediatek SoC support" , "moderated list:ARM/Mediatek SoC support" , "moderated list:ARM/Mediatek SoC support" Subject: Re: [PATCH] Input: mtk-pmic-keys - match loop with count Message-ID: References: <20260527004543.22875-1-rosenp@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260527004543.22875-1-rosenp@gmail.com> Hi Rosen, On Tue, May 26, 2026 at 05:45:43PM -0700, Rosen Penev wrote: > of_get_available_child_count is used along with > for_each_child_of_node_scoped, which can cause a mismatch when keys have > a disabled status. > > If a disabled child node exists in the device tree alongside available ones, > the loop could execute more times than the initial validation accounted for. > This might increment the index variable past the allocated array bounds, > leading to out-of-bounds accesses on irqnames[] and keys->keys[]. > > Signed-off-by: Rosen Penev > --- > drivers/input/keyboard/mtk-pmic-keys.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c > index c78d9f6d97c4..5d4ebbafd276 100644 > --- a/drivers/input/keyboard/mtk-pmic-keys.c > +++ b/drivers/input/keyboard/mtk-pmic-keys.c > @@ -363,7 +363,7 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev) > return -EINVAL; > } > > - for_each_child_of_node_scoped(node, child) { > + for_each_available_child_of_node_scoped(node, child) { > keys->keys[index].regs = &mtk_pmic_regs->keys_regs[index]; > > keys->keys[index].irq = I think Sashiko correctly points out that this may result in incorrect register data and interrupts being mapped to the keys (potentially shifting them). Maybe we should stop counting nodes separately, iterate over all of them here and bail out with an error if we encounter more than 2 (does not matter if they are marked available or not), and then skip not available nodes? WDYT? Thanks. -- Dmitry