From: Dan Carpenter <dan@pereq.eu>
To: Shunbo Shi <shishunbo@cmss.chinamobile.com>
Cc: johan@kernel.org, elder@kernel.org, gregkh@linuxfoundation.org,
greybus-dev@lists.linaro.org, linux-kernel@vger.kernel.org,
syzbot+0b456664585fa81a47f6@syzkaller.appspotmail.com
Subject: Re: [PATCH v2] greybus: verify the received message size covers the message header
Date: Thu, 12 Nov 2026 13:37:12 +0300 [thread overview]
Message-ID: <avWW2GyYe5_cUXDF@stanley.mountain> (raw)
In-Reply-To: <20261112093823.37567-1-shishunbo@cmss.chinamobile.com>
On Thu, Nov 12, 2026 at 09:38:23AM +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.
Remove the last sentence. 0 is just another example of too small and
not an interesting one.
>
> Combine the two existing checks into one that also verifies
> msg_size >= sizeof(header), so that the "Caller has made sure we
> at least have a message header" assumption in
> gb_operation_create_incoming() actually holds.
This paragraph is unnecessary. Trivial. Also calling them "existing"
is wrong.
>
> Suggested-by: Dan Carpenter <dan@pereq.eu>
No need for this when it's a response to review comments. Only
original suggestions count.
> Link: https://lore.kernel.org/all/sashiko-outbox-210716@kernel.org/T/
> 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 | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/greybus/operation.c b/drivers/greybus/operation.c
> index 7e12ffb2dd60..dcb38dc29cff 100644
> --- a/drivers/greybus/operation.c
> +++ b/drivers/greybus/operation.c
> @@ -1047,9 +1047,9 @@ 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 (size < msg_size) {
> + if (msg_size < sizeof(header) || msg_size > size) {
> dev_err_ratelimited(dev,
> - "%s: incomplete message 0x%04x of type 0x%02x received (%zu < %zu)\n",
> + "%s: incomplete or invalid message 0x%04x of type 0x%02x received (%zu < %zu)\n",
incomplete is a subset of invalid. Just say invalid. Or leave it as
incomplete if you want.
Please wait 24 hours between resends.
regards,
dan carpenter
prev parent reply other threads:[~2026-11-12 10:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 7:12 [PATCH] greybus: verify the received message size covers the message header Shunbo Shi
2026-11-12 7:17 ` sashiko-bot
2026-11-12 8:09 ` Shunbo Shi
2026-11-12 9:38 ` [PATCH v2] " Shunbo Shi
2026-11-12 10:37 ` Dan Carpenter [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=avWW2GyYe5_cUXDF@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=shishunbo@cmss.chinamobile.com \
--cc=syzbot+0b456664585fa81a47f6@syzkaller.appspotmail.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.