All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Wolfram Sang <wsa@kernel.org>, itewqq <shipeiqu@sjtu.edu.cn>,
	 linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	 Bryam Vargas <hexlabsecurity@proton.me>
Subject: Re: [PATCH] i2c: smbus: make i2c_smbus_read_block_data() safer
Date: Mon, 22 Jun 2026 22:24:01 -0700	[thread overview]
Message-ID: <ajoYKOBRXc3HrH6a@google.com> (raw)
In-Reply-To: <ZxGrwObOFkNuCn_w@google.com>

On Thu, Oct 17, 2024 at 05:28:48PM -0700, Dmitry Torokhov wrote:
> i2c_smbus_read_block_data() is dangerous to use because it may deliver
> up to I2C_SMBUS_BLOCK_MAX (32) bytes, which may be surprising to the
> caller. Callers tend to allocate buffers of sizes big enough to hold
> data from a well-behaving device and do not expect that
> i2c_smbus_read_block_data() may attempt to write more data than
> expected.
> 
> To make i2c_smbus_read_block_data() safer to use change it so that
> it accepts size of the supplied buffer as another argument and ensure
> that it will not copy more data than the size of the buffer.
> 
> To allow users to gradually transition to the new API employ some
> macro trickery allowing calling i2c_smbus_read_block_data() with either
> 3 or 4 arguments. When called with 3 arguments it is assumed that
> the buffer size is I2C_SMBUS_BLOCK_MAX bytes. Once everyone is
> transitioned to the 4 argument form the macros should be removed.
> 
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Wolfram, any chance we could get this in? I am getting patches for OOB
access because of the unexpected behavior and I'd like to fix them
without doing extra memcpy().

Thanks.

-- 
Dmitry

      reply	other threads:[~2026-06-23  5:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-18  0:28 [PATCH] i2c: smbus: make i2c_smbus_read_block_data() safer Dmitry Torokhov
2026-06-23  5:24 ` Dmitry Torokhov [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=ajoYKOBRXc3HrH6a@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=hexlabsecurity@proton.me \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shipeiqu@sjtu.edu.cn \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=wsa@kernel.org \
    /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.