All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan@pereq.eu>
To: Shunbo Shi <shishunbo@cmss.chinamobile.com>
Cc: syzbot+0b456664585fa81a47f6@syzkaller.appspotmail.com,
	elder@kernel.org, gregkh@linuxfoundation.org,
	greybus-dev@lists.linaro.org, johan@kernel.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linux-staging@lists.linux.dev, linux-usb@vger.kernel.org,
	syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH] greybus: verify the received message size covers the message header
Date: Thu, 12 Nov 2026 11:43:15 +0300	[thread overview]
Message-ID: <avV8I97uZJgX8Osk@stanley.mountain> (raw)
In-Reply-To: <20261112082230.33584-1-shishunbo@cmss.chinamobile.com>

On Thu, Nov 12, 2026 at 08:22:29AM +0000, Shunbo Shi wrote:
> In gb_connection_recv(), the size of the received data is checked
> against sizeof(struct gb_operation_msg_hdr) and against the message
> size encoded in the header (msg_size), but msg_size itself is never
> checked against the header size.
> 
> If a peer sends a message whose header claims a size smaller than
> the header itself (e.g. header.size == 3), the two existing checks
> both pass (size >= sizeof(header) and size >= msg_size), and the
> message is dispatched with the undersized msg_size.
> 
> In gb_operation_create_incoming(), this leads to an unsigned
> integer underflow in:
> 
> 	request_size = size - sizeof(struct gb_operation_msg_hdr);
> 
> The underflowed request_size then wraps back around in
> gb_operation_message_alloc():
> 
> 	message_size = payload_size + sizeof(*header);
> 
> causing kzalloc() to allocate a buffer that is too small to hold
> the message header.  When the response is later prepared in
> gb_operation_response_alloc(), reading
> request_header->operation_id reads past the end of the undersized
> allocation, triggering a KASAN slab-out-of-bounds report.  When
> header.size is zero, kzalloc(0) returns ZERO_SIZE_PTR and the
> same read dereferences an invalid address.
> 
> Verify msg_size >= sizeof(header) in gb_connection_recv() so that
> the "Caller has made sure we at least have a message header"
> assumption in gb_operation_create_incoming() actually holds.
> 
> Fixes: d90c25b0a279 ("greybus: let operation layer examine incoming data")
> Reported-by: syzbot+0b456664585fa81a47f6@syzkaller.appspotmail.com
> Closes: https://syzbot.org/bug?extid=0b456664585fa81a47f6
> Signed-off-by: Shunbo Shi <shishunbo@cmss.chinamobile.com>
> ---
>  drivers/greybus/operation.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/greybus/operation.c b/drivers/greybus/operation.c
> index 7e12ffb2dd60..da53c0e026f0 100644
> --- a/drivers/greybus/operation.c
> +++ b/drivers/greybus/operation.c
> @@ -1047,6 +1047,13 @@ void gb_connection_recv(struct gb_connection *connection,
>  	/* Use memcpy as data may be unaligned */
>  	memcpy(&header, data, sizeof(header));
>  	msg_size = le16_to_cpu(header.size);
> +	if (msg_size < sizeof(header)) {
> +		dev_err_ratelimited(dev,
> +				    "%s: invalid message header size (%zu < %zu)\n",
> +				    connection->name, msg_size,
> +				    sizeof(header));
> +		return;
> +	}
>  	if (size < msg_size) {

Combine the conditions:

	if (msg_size < sizeof(header) || msg_size > size) {

regards,
dan carpenter

>  		dev_err_ratelimited(dev,
>  				    "%s: incomplete message 0x%04x of type 0x%02x received (%zu < %zu)\n",
> -- 
> 2.53.0
> 
> 
> 

  parent reply	other threads:[~2026-11-12  8:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12  5:56 [syzbot] [greybus?] [usb?] KASAN: slab-out-of-bounds Read in gb_operation_work syzbot
2026-11-12  8:22 ` [PATCH] greybus: verify the received message size covers the message header Shunbo Shi
2026-11-12  8:27   ` sashiko-bot
2026-11-12  8:43   ` Dan Carpenter [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-11-12  7:12 Shunbo Shi
2026-11-12  7:17 ` sashiko-bot
2026-11-12  8:09 ` Shunbo Shi

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=avV8I97uZJgX8Osk@stanley.mountain \
    --to=dan@pereq.eu \
    --cc=elder@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=greybus-dev@lists.linaro.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=linux-usb@vger.kernel.org \
    --cc=shishunbo@cmss.chinamobile.com \
    --cc=syzbot+0b456664585fa81a47f6@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /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.