Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jun Yan" <jerrysteve1101@gmail.com>
Cc: dmitry.torokhov@gmail.com, devicetree@vger.kernel.org,
	linux-input@vger.kernel.org, conor+dt@kernel.org,
	robh@kernel.org
Subject: Re: [PATCH v4 10/10] Input: cap11xx - add support for CAP1114
Date: Wed, 17 Jun 2026 21:25:09 +0000	[thread overview]
Message-ID: <20260617212509.D5B6D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260617150318.753148-11-jerrysteve1101@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Out-of-bounds write in `cap11xx_i2c_probe` due to unvalidated Device Tree keycodes.
--

commit 42cef688f767435c4da8af0dd519be20d4164735
Author: Jun Yan <jerrysteve1101@gmail.com>

CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
and hardware reset support.

This commit adds support for the CAP1114 touch sensor, updating the driver
to handle up to 14 channels and 11 LED outputs. It introduces logic to
read from a secondary status register to support the expanded channel count
and configures grouped sensors as independent inputs.

> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> index 275eb79a7193..865c58533eb9 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c

[ ... ]

> @@ -292,6 +307,17 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
>  	of_property_read_u32_array(node, "linux,keycodes",
>  				   priv->keycodes, priv->model->num_channels);

[Severity: High]
This is a pre-existing issue, but I noticed that these keycodes are read
directly from the Device Tree into the priv->keycodes array without any
bounds validation.

Later during initialization in cap11xx_i2c_probe(), the driver loops over
these keycodes and sets bits using an unchecked macro:

	__set_bit(priv->keycodes[i], priv->idev->keybit);

If an exceptionally large keycode (greater than KEY_MAX) is provided via a
Device Tree overlay, could this cause an out-of-bounds write on the
priv->idev->keybit array and corrupt adjacent heap memory? Should we verify
that each keycode read from the Device Tree is less than or equal to KEY_MAX?

> +
> +	/*
> +	 * CAP1114 needs dedicated configuration to split
> +	 * grouped sensors into independent inputs.
> +	 */
> +	if (priv->model->has_grouped_sensors) {
> +		error = regmap_set_bits(priv->regmap, CAP1114_REG_CONFIG2,
> +					CAP1114_REG_CONFIG2_VOL_UP_DOWN);
> +		if (error)
> +			return error;
> +	}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260617150318.753148-1-jerrysteve1101@gmail.com?part=10

      reply	other threads:[~2026-06-17 21:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-17 15:02 [PATCH v4 00/10] Input: cap11xx - Add support for CAP1114 Jun Yan
2026-06-17 15:02 ` [PATCH v4 01/10] Input: cap11xx - clean up duplicate log and add probe error logs Jun Yan
2026-06-17 15:02 ` [PATCH v4 02/10] Input: cap11xx - remove unused register macros Jun Yan
2026-06-17 20:21   ` sashiko-bot
2026-06-17 15:02 ` [PATCH v4 03/10] dt-bindings: input: microchip,cap11xx: Update datasheet URL and LED reg range Jun Yan
2026-06-17 20:31   ` sashiko-bot
2026-06-17 15:02 ` [PATCH v4 04/10] dt-bindings: input: microchip,cap11xx: Add microchip,cap1126 LED reg constraints Jun Yan
2026-06-17 15:02 ` [PATCH v4 05/10] dt-bindings: input: microchip,cap11xx: Add reset-gpios property Jun Yan
2026-06-17 15:02 ` [PATCH v4 06/10] Input: cap11xx - add reset gpio support Jun Yan
2026-06-17 15:02 ` [PATCH v4 07/10] Input: cap11xx - refactor code for better CAP1114 support Jun Yan
2026-06-17 20:57   ` sashiko-bot
2026-06-17 15:02 ` [PATCH v4 08/10] Input: cap11xx - guard unsupported DT properties before parsing Jun Yan
2026-06-17 15:02 ` [PATCH v4 09/10] dt-bindings: input: microchip,cap11xx: Add CAP1114 support Jun Yan
2026-06-17 21:15   ` sashiko-bot
2026-06-17 15:02 ` [PATCH v4 10/10] Input: cap11xx - add support for CAP1114 Jun Yan
2026-06-17 21:25   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260617212509.D5B6D1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jerrysteve1101@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox