From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 0BC99459AD7 for ; Tue, 25 Aug 2026 14:12:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787667132; cv=none; b=gdWXHYpRESGTwqfhbv0aUm6Ico2mUixNcvgoKt84BzHnUrihNoi7NJDtwXbpsvDGXVS7YqdQlkSxaR/wEYaFoUQkDocLEdvSJXBouDMAC5WWp4A7z36x7etJuMpbYmo8beRv5599oPkity2umDW6RxcfBZvb+tmT3HYFw+8HO8k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787667132; c=relaxed/simple; bh=ks8Gq1TVMbNgqf1hMytUJDDO9X8kUUIiY+pU4x+tOKM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kKdRQqhBuOa+3RnR0O+zO8G6hGsIg/CKxu4TMnnp4MEzqY+YzkX1mpcJQLrUHc4WEJ3kI6AI+d/cijrzwlRyX2jYoIG3fL0dlipLwMKfto0Ti/sPGDAa3OfNDwPzC04YQjkw1UCkgyZ10ta/5U1e6M/gjmcV+aLBPkZM1czOwec= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TAdJTWaJ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TAdJTWaJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A105D1F000E9; Tue, 25 Aug 2026 14:12:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787667130; bh=mSTOdvYH0f07G+ooxNeJ29QKOfX/5ufIG+QX8dr85nc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=TAdJTWaJ7Y2IAHDECZVnN2YYU08yF5Aq9Ak/5VU1yg52XXB9aAdvk4JaIj/yyL7S/ WpUva8j2hKni9zvnudKt+sw374M+DhtGaN6C+EPUwuNvYcBy+PENk98LNEsdhfR+FI 9w3OukN9egzSzWcoP7Lm1kI2vxZWza+PwbryxOoki0bBG/mf+OMgqQxmE+R7mMZ4wk XaFhwQXb4pSyTErShZPbUBWs8SW8akJpwP+N/UspRG0k6LHs+MEzVNEDUNx6OcFxCn STmN8VpCj2bXTWEM/JzMcAbxoJZsShzXo9npxOrd74KJayzfHeLOLx4Zr85IBbeYWK mWIfYw6XNF9xg== Received: from johan by xi.lan with local (Exim 4.99.4) (envelope-from ) id 1wyrsm-000000023YV-0uTZ; Tue, 25 Aug 2026 16:12:08 +0200 Date: Tue, 25 Aug 2026 16:12:08 +0200 From: Johan Hovold To: Yang Zi <2959243019@qq.com> Cc: elder@kernel.org, gregkh@linuxfoundation.org, greybus-dev@lists.linaro.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] greybus: operation: Fix NULL pointer dereference in gb_operation_message_alloc() Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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