From: sashiko-bot@kernel.org
To: "Sang-Heon Jeon" <ekffu200098@gmail.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
Subject: Re: [PATCH v2 2/3] Input: rmi_smbus - remove conditional return with no effect
Date: Wed, 29 Jul 2026 17:17:58 +0000 [thread overview]
Message-ID: <20260729171758.84C0B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260729171001.260698-3-ekffu200098@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Buffer overflow in smb_block_read() due to ignoring the requested length.
- [High] Out-of-bounds read in rmi_smb_write_block() due to using the total length instead of the remaining length.
--
--- Patch [2]: [PATCH v2 2/3] Input: rmi_smbus - remove conditional return with no effect ---
commit c43fcefd3c43ed84b5f32f45bd591ace30890382
Author: Sang-Heon Jeon <ekffu200098@gmail.com>
Input: rmi_smbus - remove conditional return with no effect
This patch simplifies the return path in smb_block_read() by removing an
unnecessary conditional check. Both branches of the check returned the same
value, so it now returns the result of i2c_smbus_read_block_data() directly.
> diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
> index 6de68c602558b..3160714a514a5 100644
> --- a/drivers/input/rmi4/rmi_smbus.c
> +++ b/drivers/input/rmi4/rmi_smbus.c
> @@ -177,13 +177,8 @@ static int smb_block_read(struct rmi_transport_dev *xport,
> struct rmi_smb_xport *rmi_smb =
> container_of(xport, struct rmi_smb_xport, xport);
> struct i2c_client *client = rmi_smb->client;
> - int retval;
>
> - retval = i2c_smbus_read_block_data(client, commandcode, buf);
> - if (retval < 0)
> - return retval;
> -
> - return retval;
> + return i2c_smbus_read_block_data(client, commandcode, buf);
> }
[Severity: High]
This is a pre-existing issue, but by removing the intermediate check, it draws
attention to a buffer overflow in this function.
Can this corrupt memory? The smb_block_read() function takes a len parameter,
but it is completely ignored when calling i2c_smbus_read_block_data().
If a malicious or buggy I2C device returns up to 32 bytes (SMB_MAX_COUNT),
i2c_smbus_read_block_data() will copy that full amount into buf. If the
original len was less than 32 (for instance, on the final chunk of a read in
rmi_smb_read_block()), this could overflow the buffer and corrupt memory.
>
> static int rmi_smb_read_block(struct rmi_transport_dev *xport, u16 rmiaddr,
> void *databuff, size_t len)
> {
[ ... ]
While reviewing this, I also noticed another pre-existing issue in the nearby
rmi_smb_write_block() function:
drivers/input/rmi4/rmi_smbus.c:rmi_smb_write_block() {
...
while (cur_len > 0) {
/*
* break into 32 bytes chunks to write get command code
*/
int block_len = min_t(int, len, SMB_MAX_COUNT);
...
}
[Severity: High]
This is a pre-existing issue, but can this lead to an out-of-bounds read?
When chunking the write, the loop calculates block_len using the original total
len instead of the remaining cur_len.
If len is greater than 32, block_len will remain exactly 32 for every
iteration, even the final one where fewer than 32 bytes remain. This causes
smb_block_write() to read 32 bytes starting from the advanced databuff
pointer, potentially reading past the end of the original buffer.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260729171001.260698-1-ekffu200098@gmail.com?part=2
next prev parent reply other threads:[~2026-07-29 17:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 17:09 [PATCH v2 0/3] Input: clean up conditional returns with no effect Sang-Heon Jeon
2026-07-29 17:09 ` [PATCH v2 1/3] Input: pmic8xxx-keypad - remove conditional return " Sang-Heon Jeon
2026-07-29 17:09 ` [PATCH v2 2/3] Input: rmi_smbus " Sang-Heon Jeon
2026-07-29 17:17 ` sashiko-bot [this message]
2026-07-29 17:09 ` [PATCH v2 3/3] Input: synaptics_i2c - return 0 explicitly on success Sang-Heon Jeon
2026-07-29 17:16 ` sashiko-bot
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=20260729171758.84C0B1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=ekffu200098@gmail.com \
--cc=linux-input@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.