From nobody Mon Sep 28 07:23:09 2026 Received: from out162-62-58-216.mail.qq.com (out162-62-58-216.mail.qq.com [162.62.58.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 24F493E63B2 for ; Tue, 25 Aug 2026 09:23:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=162.62.58.216 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787649800; cv=none; b=vAqYwDEIgG+nG1JE6R/9uI/oLr7aabBw60bcxyUmmDNpcUpJTHjhjzO0djFrsWdk0C+wImR1sUvcxwVcfpctJbGuvMyOibH81b+WbbWsedJr94q+MaCXQuJNJmrhSooyc1i9AAIEgkEjRHaan3N1N1zTLwFMVxkyjXGphhxbRPg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787649800; c=relaxed/simple; bh=BejXH+qgPT7Cqy4EUaPj9cqpZPPX5Dm8f+RS8ggkjnI=; h=Message-ID:Date:MIME-Version:To:Cc:From:Subject:Content-Type; b=fdIFzIEUjfWJNezUT6bMyq5A8gvJ2uOD+OU1Q/bWHDGgFEWgbtN+itpkmHOvoe1wJkOEHU8jOpDB2FCa+GmsX+ydUmxj/8tpxynYWG4hmzDwn0FIrmeFXNm8pwhE9vznCEX5syuzJyukJN5gNompojKfGTCay5ssu+0utnoTCkU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com; spf=pass smtp.mailfrom=qq.com; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b=TAaO8xDF; arc=none smtp.client-ip=162.62.58.216 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qq.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b="TAaO8xDF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1787649793; bh=BejXH+qgPT7Cqy4EUaPj9cqpZPPX5Dm8f+RS8ggkjnI=; h=Date:To:Cc:From:Subject; b=TAaO8xDFuyNRPmd5GWANQva06BdDttka9xDRqgf6L+J8axmRVcZR6XrRfIvf2B4Bu 3GGmZkL2ow6nEOvCQPi0Sdbvaet+Edep70d/gnF7cKs8CzHTP6KE9Z2x7bx8pcfYox C6DORmDFJwlaUUW5gQdKbnS7j4u2RQW3HRhLmAfw= Received: from [192.168.255.10] ([111.206.96.146]) by newxmesmtplogicsvrsza63-0.qq.com (NewEsmtp) with SMTP id 5CAA4628; Tue, 25 Aug 2026 17:23:10 +0800 X-QQ-mid: xmsmtpt1787649790too2ceo1f Message-ID: X-QQ-XMAILINFO: Ni/OWY1crZtLk/273wD0iRw5bc8G8i9E83s78rZkPsPUmzkshqwCGSshY5Q/ma y/W02UuzksAa1YB9a74Xvf/PQUkQ/ArPNWAy8mdPaHke+eEVoYlOy5kNQiBpbhIRQbeyXCKjetJ+ BvcFKoKiVSrg6O9oYaG97/fTjMOnFQTxv9sbwPfRG299kR2jwaSFIZBQQ4093gtyorSFduzNH7GO 69Cym6hAN5+YM7o7mVmfEOVUtbIEJxqdgXyfcYkpiRDWBf59UrL9O0jdjI+3xx2bi9dBzcEkXG1D ANhHsXZNWHRd6NSk41EZ+qi21LLH+8pf14NRohPDgwcDX5XZzVtxFBG2ofwi3jkp8BWoXGT1ygGu fu4zkp6LoXam7RtYccBfCUzrdNFzivHNtfXHKzToZncQLY1hNTdRFTs+vcnHsfRjG9tWNDirOiLu PrQVYSn4XeLUPxU0RLY3zrQsVjM/WaW4ZzWNoSRJscmNqhOThCsRhp/XrYPLXkmCW66FiplqkyaZ pqg8eNWJ6uH/7aE7vqvonUbwOghpV4uG70q0NSnVmNy34QdCMWeerDXglwEnmr+t0VTY01X/jV3G Rbe/ToiyggBlrQtLiaaddn0YQ8E3xtgi1Ky24SJccJ+fe8de1E7cz7x1Sz/pEQaQj+VuFKlPujJH dC8PtiKTqBKAJkvGQqve9kx4FYWwXwqcFv/o/jfyjxwplVJO/TQHDeD3humywq7BzrGqRzpENMOM K1EHtsJiu8qBH0vuJWpV6tvpXe5dpFcmsY3ZsqCmQsePUDgD0S00C+C+m9tKKAKumBiyf/yZEq79 hX4maIwT960H67+o1WF50LJeYAzNFr3b25s0ZK3wAr43bi4mNHFBs0u/MxC2FhrS4aA4+bc2lP74 EgSjemXExASmwh5ICuXbfYrSGj87m5NcIQYJmarIrcjLn+o6erc5aHvMoSYmO8XE7FACZwJhK7Js PFEijKCRpDieSzNPtib8No0Tasgka4Ul8068Zwc7mjIzLIWflUMAhReb62s/95hu0LdJOKnZWkq5 WA3pRgrnXVh7bWufybYQAKxubS3+hfHR4dYqnPbIWpVPpzwAYMY1onLrSJzFvEowdkjngmCsNCin VRY1pUTHFkdUtvNZs= X-QQ-XMRINFO: OD9hHCdaPRBwH5bRRRw8tsiH4UAatJqXfg== X-OQ-MSGID: Date: Tue, 25 Aug 2026 17:23:09 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: johan@kernel.org, elder@kernel.org, gregkh@linuxfoundation.org, greybus-dev@lists.linaro.org Cc: linux-kernel@vger.kernel.org From: Yang Zi <2959243019@qq.com> Subject: [PATCH] greybus: operation: Fix NULL pointer dereference in gb_operation_message_alloc() Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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.=C2=A0 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 =3D size - sizeof(struct gb_operation_msg_hdr) underflows to SIZE_MAX - 7, and in gb_operation_message_alloc() message_size =3D 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: =C2=A0 =C2=A0 BUG: KASAN: null-ptr-deref in gb_operation_message_init drive= rs/greybus/operation.c:340 [inline] [greybus] =C2=A0 =C2=A0 BUG: KASAN: null-ptr-deref in gb_operation_message_alloc+0xab= 4/0xdb0 drivers/greybus/operation.c:385 [greybus] =C2=A0 =C2=A0 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> --- =C2=A0drivers/greybus/operation.c | 15 +++++++++++---- =C2=A01 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/greybus/operation.c b/drivers/greybus/operation.c index 7e12ffb2dd60..c3d51176c373 100644 --- a/drivers/greybus/operation.c +++ b/drivers/greybus/operation.c @@ -364,14 +364,21 @@ gb_operation_message_alloc(struct gb_host_device *hd,= u8 type, =C2=A0{ =C2=A0 =C2=A0 =C2=A0struct gb_message *message; =C2=A0 =C2=A0 =C2=A0struct gb_operation_msg_hdr *header; -=C2=A0 =C2=A0 size_t message_size =3D payload_size + sizeof(*header); +=C2=A0 =C2=A0 size_t message_size; =C2=A0 -=C2=A0 =C2=A0 if (message_size > hd->buffer_size_max) { +=C2=A0 =C2=A0 /* +=C2=A0 =C2=A0 =C2=A0* Reject a payload size that would make the total mess= age size +=C2=A0 =C2=A0 =C2=A0* overflow, before it wraps around and bypasses the ma= ximum +=C2=A0 =C2=A0 =C2=A0* buffer size check. +=C2=A0 =C2=A0 =C2=A0*/ +=C2=A0 =C2=A0 if (payload_size > hd->buffer_size_max - sizeof(*header)) { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_warn(&hd->dev, "requested message siz= e too big (%zu > %zu)\n", -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0message_size, hd->buffer_s= ize_max); +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0payload_size, hd->buffer_s= ize_max - sizeof(*header)); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return NULL; =C2=A0 =C2=A0 =C2=A0} =C2=A0 +=C2=A0 =C2=A0 message_size =3D payload_size + sizeof(*header); + =C2=A0 =C2=A0 =C2=A0/* Allocate the message structure and buffer. */ =C2=A0 =C2=A0 =C2=A0message =3D kmem_cache_zalloc(gb_message_cache, gfp_fla= gs); =C2=A0 =C2=A0 =C2=A0if (!message) @@ -1047,6 +1054,11 @@ void gb_connection_recv(struct gb_connection *connec= tion, =C2=A0 =C2=A0 =C2=A0/* Use memcpy as data may be unaligned */ =C2=A0 =C2=A0 =C2=A0memcpy(&header, data, sizeof(header)); =C2=A0 =C2=A0 =C2=A0msg_size =3D le16_to_cpu(header.size); +=C2=A0 =C2=A0 if (msg_size < sizeof(header)) { +=C2=A0 =C2=A0 =C2=A0 =C2=A0 dev_err_ratelimited(dev, "%s: short message re= ceived (%zu < %zu)\n", +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conn= ection->name, msg_size, sizeof(header)); +=C2=A0 =C2=A0 =C2=A0 =C2=A0 return; +=C2=A0 =C2=A0 } =C2=A0 =C2=A0 =C2=A0if (size < msg_size) { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_err_ratelimited(dev, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"%s: incomplete message 0x%04x of type 0x%02x received (%zu < %zu)\n",