From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 4DF8226158C for ; Thu, 16 Apr 2026 21:44:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776375888; cv=none; b=Gx2owATlZGahKdtvxko4XUcUbTcmpEHxBMTy2IB96gXt5F5H9+gsGsB4s62AVLfeySL7R7RSLsJfeC4hEspwiIjwGCbKiKSkUb/tPwMS6Lwsi+gcOpRQoLB+H+faFdMmffnh0WGYkNsbYJ6eN1cQSaJf4NiFysZJJ3aop0LxTAk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776375888; c=relaxed/simple; bh=Ng77UU+5RbrbdRpLBR0N0peiElG8uwGglBRSRXNZEAI=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=gbxMvRFRggyqW2XZR45hL3062IKI/VMNDYraQ8WbSWHjaruGl5g9Khy8Vxgpi6+8EoTBmKTMTR9QTFBsOMcOLUloDrO7xTWXGuMncQgdQiHwLFKpfuscb3sJPLHv9oA+RKpUS6S9+XvjD/+LcFdukdYJYXWKiZeShyIr15k7rsk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qCkATr0d; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qCkATr0d" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7713C2BCAF; Thu, 16 Apr 2026 21:44:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776375888; bh=Ng77UU+5RbrbdRpLBR0N0peiElG8uwGglBRSRXNZEAI=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From; b=qCkATr0dun8DmxO7W6Fbm4NeTHBOBrfyh4HSbD2kwOxubOv08LkdRFoluiD9wmJc4 K4aUIr1OnK5jiRpXYiweM641pr4zPR+4aPcmYz1dKMc0/ApS3swq2/ZETtr3UY0F9w jABPTJphcFxbdlWo65MPZ5yfrwG1y8XT/LerZcssPTHQvZrPhw6fkbbV6a6KraK9TX mXooxBwP8W3u0WyA35exs0z7iodZC1gdwGBjg/tfVjtH/y8TdBRkrUNLfipe9l8oWr 7qUOfgHpOmxeGJcmMk8ZI7CC75QrHz6h8jYBRpHiIB7cAi+lO0NnK5xL/ue8hvi7ab ObnmC1t7Dm82Q== From: sashiko-bot@kernel.org Subject: Re: [PATCH v4 08/10] hornet: Add a light skeleton data extractor scripts Reply-To: sashiko@lists.linux.dev To: "Blaise Boscaccy" Cc: bpf@vger.kernel.org In-Reply-To: <20260416173500.176716-9-bboscaccy@linux.microsoft.com> References: <20260416173500.176716-9-bboscaccy@linux.microsoft.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2026 21:44:47 +0000 Message-Id: <20260416214447.D7713C2BCAF@smtp.kernel.org> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Sashiko AI review found 4 potential issue(s): - [High] Unquoted `printf $(...)` causes binary data corruption and format = string evaluation. - [High] Overly broad `grep` patterns match struct assignments, leading to = payload duplication. - [Medium] Unquoted script argument `$1` allows command-line argument injec= tion in `gcc`. - [Low] Redundant and duplicate scripts create unnecessary maintenance burd= en. -- commit 18ddbefea00184030f4d5a0c406b61b4fd5670fd Author: Blaise Boscaccy hornet: Add a light skeleton data extractor scripts This commit introduces scripts to extract eBPF instruction and map data payloads from autogenerated light skeleton headers for use in signing. > diff --git a/scripts/hornet/extract-insn.sh b/scripts/hornet/extract-insn= .sh > new file mode 100755 > index 0000000000000..52338f057ff6b > --- /dev/null > +++ b/scripts/hornet/extract-insn.sh [ ... ] > +if [ $ARGC -ne $EXPECTED_ARGS ] ; then > + usage > +else > + printf $(gcc -E $1 | grep "opts_insn" | \ ^^ Could an unquoted $1 cause gcc to interpret filenames starting with a hyphen as command-line options, or fail if the path contains spaces? > + awk -F"=3D" '{print $2}' | sed 's/;\+$//' | sed 's/\"//g') Does this overly broad grep match both the array declarations and subsequent struct assignments? If grep matches opts.insns =3D (void *)opts_insn;, the pipeline will extract both the hex payload and the struct assignment, leading to payload duplicat= ion. Also, can this printf $(...) construct corrupt the binary data? If the extracted payload contains the byte 0x25 (%), printf will evaluate it as a format specifier. For example, \x25\x64 (%d) will evaluate to 0. If the payload starts with a hyphen, printf will interpret it as an option. > diff --git a/scripts/hornet/extract-map.sh b/scripts/hornet/extract-map.sh > new file mode 100755 > index 0000000000000..c309f505c6238 > --- /dev/null > +++ b/scripts/hornet/extract-map.sh [ ... ] > +if [ $ARGC -ne $EXPECTED_ARGS ] ; then > + usage > +else > + printf $(gcc -E $1 | grep "opts_data" | \ > + awk -F"=3D" '{print $2}' | sed 's/;\+$//' | sed 's/\"//g') > +fi This isn't a bug, but extract-insn.sh and extract-map.sh appear to duplicate the functionality of extract-skel.sh, which cleanly accepts the target field (insn or data) as a command-line parameter. Could these redundant scripts be consolidated to avoid duplicating the unquoted printf and grep issues across multiple files? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260416173500.1767= 16-1-bboscaccy@linux.microsoft.com?part=3D8