From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (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 746274908D7 for ; Sat, 25 Jul 2026 00:47:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784940432; cv=none; b=Dng+oJlorT79/J5qmOQLXI1iFcUcMxMlnZKn4R/TL+CwIpBqsso50P+62Kwie2UQE07XYRhnsiDrCpfWR3dt1BU1Tak4xq+tNPoKKOQFt08rpdB5brCmHPkKASSlNeZGyFRXHN42u/zv7EuxrNjHcOPs0vuU6j+APJJc8pSIukc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784940432; c=relaxed/simple; bh=UJVA9+EOL1W+AO6b9PWinnVn9nww4fVVLjqsLiybgIk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oK8vPpdUorhWGkMsWZp3EVvT7PncfDklTnzTVwlGX8CNrevMSGVCuNkr/dYuVZtrKfwn18PJ7lS7L9JjCACqFZNC0TnTpAJiILrFrn4rzsWWcpOiy2Cy5C48ZdTunwscN6Uowj472zNu843K20WMWW3B+jLQ2MRhosmLInLiAvA= 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=X20XkpRt; arc=none smtp.client-ip=209.85.216.41 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="X20XkpRt" Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-38e08baf860so1034717a91.2 for ; Fri, 24 Jul 2026 17:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784940431; x=1785545231; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=nLa0EMw9PWWGmtr3YMFJ2UkiiCRgohdNwEzulmVed7c=; b=X20XkpRtrqo80eIO8rjbrIPG9UlcXMVrdg/RJXAyDSPCkYyFg6WjYBjx4iJ/ENJ4gp NQA43R9bKPhKBpPoYUY014esc/9m8aMvwl5U60APrFM4mqfbrDZblylYAMpUnOSMOE1z 4zxeEclL4DcoNmF6MVG5ZEiz6WBkOl9RR+YoflSuQdS1/+TIhH4sKcsWK/BLY8pl4jZb Cr2DfDDwxs2kuquV3IzAe1e9PJVDrpqyqGAw8wKQ8k2c02YTBYf5z62TuA52qA8I0Bes tp+t7rtDnyD5Z4oSwtOlHMfiejUYvEKwYtu5lJ9ENe3WxwIbhKFzhtFJkY978Xxkp+8E UXCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784940431; x=1785545231; h=in-reply-to:content-transfer-encoding:content-disposition :content-type: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:content-type; bh=nLa0EMw9PWWGmtr3YMFJ2UkiiCRgohdNwEzulmVed7c=; b=enSrxMC8dtjTcruMJzLJ+fJoBBloyoyqMrYI5gZIDbm1rOjeTnHQCHhQKAYqbVYtdB HycmSM/520RIFk7SYVSR6vdnsfcCjHRBPqlDJfYjckQY8Vp+xbncT2cq/TBdhQFnX3Zb Y852wp9XG9wLg7k8wvnZEMatPbnE7mRSkM28dtD92yWIC0YaxXnIlc5RsiJOuq6Q8FnP 4I1v6TGQUZxxR/VQ33wiGpASZmGQ571G6X0PKjTEqCuiyo3eKv1zhUG3RlU+nJ24fDy7 3OVib4QhzZDo8tHF6u+irYom/pACspQlSrEoXaO7SuEA3Wh/HTAQ4uAEreC1+U+ddz1B FJmw== X-Forwarded-Encrypted: i=1; AHgh+RqneKDqZsyRigtxFTAzKvCijSQq+Dz2nghUQhFRDwRgQK6PPLj2mabmm36lIe7RP+tki9YCdbzrdA5a0FA=@vger.kernel.org X-Gm-Message-State: AOJu0YzYjTh/+YbNkF3dwi9CR2TxOowt2Y2/RnM78W41fX9o83bkTEus yLmvIWX5grrhskxhBPthofJHPPW8xy0bICH7rZZtvhDYpMwZhS6Ex6So X-Gm-Gg: AR+sD13mfz1Zuq1edoUW+x6XdgPBaT7/Q0cRxg7PUaPgwyy6J2oDCkbWCcbONXm+aVr 3vlBYCNVLAGM4ffPqf9LcgRy8o45n3iWKMO2rBioUob98OT9Vz+Pm4WwnH0gYUXElI+RJLmP6nx sDab7wJp8N41i9CyrH0+s7oBxeExsdCbcjEJB5JMBcnlmpfUSKQyvk0FlUfybP7rirhKK4O9Gn2 9EyMq0O7XZN1fO6K9zDcQsVkZZnP6ZhwLdkWZAeiILrm8ffcDVAL8bEiUSsh4ahs51oJiZHQ99y 2v6WerZFVVFkvAau4o9l6ny8YDkYduyS2iTbRFti9+/4hQgDjPdqF+4elFLgCU0K8exSK9labak IlBaG0XyPMCR0IGn0ltYeBlX2zKi58TcfEgDEF3nL82+y/idsC6Jf6kGL5RQlh1yDWLMCKyZFun kXgroT1ST1+laDgbrWzOj6gllsPXnfg+MJ31Wnto5o9Ig= X-Received: by 2002:a17:90b:3b83:b0:387:e0db:3d8e with SMTP id 98e67ed59e1d1-38f298857damr611643a91.41.1784940430666; Fri, 24 Jul 2026 17:47:10 -0700 (PDT) Received: from google.com ([2a00:79e0:2ebe:8:40e1:40e4:dabe:543e]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13d130f55c6sm48048249c88.15.2026.07.24.17.47.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jul 2026 17:47:09 -0700 (PDT) Date: Fri, 24 Jul 2026 17:47:06 -0700 From: Dmitry Torokhov To: Liang Zhan Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Input: tca8418_keypad - fix potential infinite loop and OOB, access on I2C error Message-ID: References: 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi Liang, On Thu, Jul 23, 2026 at 11:41:43AM +0800, Liang Zhan wrote: > From 187224ee38e19fd3f74bfc08d1908c97398fef82 Mon Sep 17 00:00:00 2001 > From: Zhian Liang > Date: Thu, 23 Jul 2026 00:08:15 +0800 > Subject: [PATCH] Input: tca8418_keypad - fix potential infinite loop and OOB >  access on I2C error > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > If the I2C bus returns 0xFF (e.g., due to a stuck bus or device fault), > the original code would treat it as a valid key event, leading to two > critical issues: > 1. The loop in tca8418_read_keypad() would never terminate because the >    condition "reg <= 0" is false for 0xFF (255). This stalls the threaded >    IRQ handler indefinitely. Not everything that Sashiko generates needs to be taken literally. If transfer glitches I expect I2C core signal this properly. > 2. The extracted hardware keycode (127) is used to compute row/col >    indices that exceed the valid range (rows*cols ≤ 80), causing an >    out-of-bounds read on "keymap[code]" when reporting the key. > Fix both by: > - Recognizing 0xFF as an empty FIFO condition (along with 0x00). > - Validating the keycode before calculating row/col, skipping invalid >   codes and preventing array overrun. > Cc: stable@vger.kernel.org > Signed-off-by: Zhian Liang > --- >  drivers/input/keyboard/tca8418_keypad.c | 11 +++++++++-- >  1 file changed, 9 insertions(+), 2 deletions(-) > diff --git a/drivers/input/keyboard/tca8418_keypad.c > b/drivers/input/keyboard/tca8418_keypad.c > index b124e576feca..cec6a589192d 100644 > --- a/drivers/input/keyboard/tca8418_keypad.c > +++ b/drivers/input/keyboard/tca8418_keypad.c > @@ -171,13 +171,20 @@ static void tca8418_read_keypad(struct tca8418_keypad > *keypad_data) >             break; >         } > -       /* Assume that key code 0 signifies empty FIFO */ > -       if (reg <= 0) > +       /* 0x00 =  empty FIFO, 0xFF = likely bus fault */ > +       if (reg == 0 || reg == 0xFF) >             break; >         state = reg & KEY_EVENT_VALUE; >         code  = reg & KEY_EVENT_CODE; Jet's move the check for empty FIFO here: if (!code) return; > +       /* validate keycode: must be non-zero and within hardware limits */ > +       if (code == 0 || code > TCA8418_MAX_ROWS * TCA8418_MAX_COLS){ This check is not sufficient if keypad is configured to use just part of potential matrix. We need to make sure that row and col is within the rows and cold limits we set up for the keypad. Thanks. -- Dmitry