All of lore.kernel.org
 help / color / mirror / Atom feed
From: "zhangxiaomeng (A)" <zhangxiaomeng13@huawei.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "mhiramat@kernel.org" <mhiramat@kernel.org>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"wsa@kernel.org" <wsa@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-trace-kernel@vger.kernel.org"
	<linux-trace-kernel@vger.kernel.org>
Subject: 回复: [PATCH] i2c: Fix OOB access in trace_event_raw_event_smbus_write
Date: Tue, 9 Sep 2025 09:30:03 +0000	[thread overview]
Message-ID: <39437e40a6f14c5189e86cffb0b6abb5@huawei.com> (raw)
In-Reply-To: <20250902154957.7987e5ff@batman.local.home>

I previously attempted to apply a fix within the i2cdev_ioctl_smbus function. While this approach was successful in preventing the warning, I found that the required changes were quite extensive. The WARN is triggered by the trace_smbus_write tracepoint, which performs a memcpy(__entry->buf, data->block, len) for write operations on three specific block protocols: I2C_SMBUS_BLOCK_DATA, I2C_SMBUS_I2C_BLOCK_DATA, and I2C_SMBUS_BLOCK_PROC_CALL. To fix this in i2cdev_ioctl_smbus, it would be necessary to add checks for all three of these cases, which makes the solution rather complex.

--xiaomeng
-----邮件原件-----
发件人: Steven Rostedt <rostedt@goodmis.org> 
发送时间: 2025年9月3日 3:50
收件人: zhangxiaomeng (A) <zhangxiaomeng13@huawei.com>
抄送: mhiramat@kernel.org; dhowells@redhat.com; wsa@kernel.org; linux-kernel@vger.kernel.org; linux-trace-kernel@vger.kernel.org
主题: Re: [PATCH] i2c: Fix OOB access in trace_event_raw_event_smbus_write

On Thu, 21 Aug 2025 01:23:12 +0000
Xiaomeng Zhang <zhangxiaomeng13@huawei.com> wrote:

> The smbus_write tracepoint copies __entry->len bytes into a fixed 
> I2C_SMBUS_BLOCK_MAX + 2 buffer. Oversized lengths (e.g., 46) exceed 
> the destination and over-read the source buffer, triggering OOB 
> warning:
> 
> memcpy: detected field-spanning write (size 48) of single field 
> "entry->buf" at include/trace/events/smbus.h:60 (size 34)
> 
> Clamp the copy size to I2C_SMBUS_BLOCK_MAX + 2 before memcpy().
> This only affects tracing and does not change I2C transfer behavior.
> 
> Fixes: 8a325997d95d ("i2c: Add message transfer tracepoints for SMBUS 
> [ver #2]")
> Signed-off-by: Xiaomeng Zhang <zhangxiaomeng13@huawei.com>
> ---
>  include/trace/events/smbus.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/trace/events/smbus.h 
> b/include/trace/events/smbus.h index 71a87edfc46d..e306d8b928c3 100644
> --- a/include/trace/events/smbus.h
> +++ b/include/trace/events/smbus.h
> @@ -57,6 +57,8 @@ TRACE_EVENT_CONDITION(smbus_write,
>  		case I2C_SMBUS_I2C_BLOCK_DATA:
>  			__entry->len = data->block[0] + 1;
>  		copy:
> +			if (__entry->len > I2C_SMBUS_BLOCK_MAX + 2)
> +				__entry->len = I2C_SMBUS_BLOCK_MAX + 2;
>  			memcpy(__entry->buf, data->block, __entry->len);
>  			break;
>  		case I2C_SMBUS_QUICK:

The code has:

                switch (protocol) {
                case I2C_SMBUS_BYTE_DATA:
                        __entry->len = 1;
                        goto copy;
                case I2C_SMBUS_WORD_DATA:
                case I2C_SMBUS_PROC_CALL:
                        __entry->len = 2;
                        goto copy;
                case I2C_SMBUS_BLOCK_DATA:
                case I2C_SMBUS_BLOCK_PROC_CALL:
                case I2C_SMBUS_I2C_BLOCK_DATA:
                        __entry->len = data->block[0] + 1;
                copy:   
                        memcpy(__entry->buf, data->block, __entry->len);
                        break;
                case I2C_SMBUS_QUICK:
                case I2C_SMBUS_BYTE:
                case I2C_SMBUS_I2C_BLOCK_BROKEN:
                default:
                        __entry->len = 0;
                }

I only see two calls to the copy where one is len = 1 and the other is len = 2. Why not put the check before the copy label?

-- Steve


      reply	other threads:[~2025-09-09  9:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-21  1:23 [PATCH] i2c: Fix OOB access in trace_event_raw_event_smbus_write Xiaomeng Zhang
2025-09-02 19:49 ` Steven Rostedt
2025-09-09  9:30   ` zhangxiaomeng (A) [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=39437e40a6f14c5189e86cffb0b6abb5@huawei.com \
    --to=zhangxiaomeng13@huawei.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.org \
    --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.