On Tue, Aug 25, 2026 at 05:23:09PM +0800, Yang Zi wrote:

gb_connection_recv() reads msg_size from the received message header but only rejects it when it is larger than the received buffer ("size < msg_size"); it does not reject msg_size smaller than the message header itself.  A malicious or corrupted header.size of 0 passes that check and is forwarded to gb_operation_create_incoming() with size 0.

There, request_size = size - sizeof(struct gb_operation_msg_hdr) underflows to SIZE_MAX - 7, and in gb_operation_message_alloc() message_size = payload_size + sizeof(*header) wraps back around to 0. The "message_size > hd->buffer_size_max" check is therefore bypassed, kzalloc(0) returns ZERO_SIZE_PTR, and gb_operation_message_init() writes header->size to that pointer.

KASAN report:

BUG: KASAN: null-ptr-deref in gb_operation_message_init drivers/greybus/operation.c:340 [inline] [greybus]     BUG: KASAN: null-ptr-deref in gb_operation_message_alloc+0xab4/0xdb0 drivers/greybus/operation.c:385 [greybus]     Write of size 2 at addr 0000000000000010 by task syz.0.1/1100

Fix this by rejecting messages whose claimed size is smaller than the message header in gb_connection_recv(), and additionally make gb_operation_message_alloc() overflow-safe by comparing the payload size against hd->buffer_size_max - sizeof(*header) before adding the header size.

Signed-off-by: Yang Zi 2959243019@qq.com

How was this issue found and fixed? Did you use an LLM and are missing an Assisted-by tag?

Based on a quick glance, this look correct, but your patch is corrupt and cannot be applied. (This appears to be the case with all the 30+ patches you sent out today.)

Please fix your mail setup and send a v2 (try sending it to yourself first and make sure you can apply it and run checkpatch on it). You should look into using git-send-email.

Johan