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 13014274B3B for ; Wed, 29 Apr 2026 23:47:59 +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=1777506480; cv=none; b=NvY7iaRHqyy+sbwubsswAU/qu79MixKT0MuqVLOGzW9aoF1uPiMFqQxvPWznLFyf9BgsangREqBOrYBQJfg486MaDmGfVeZiSee83TtPmfcHZbzlW2NZFAmPTb7jxOqNGv8B+ZR2PZDFMFRZDpPKuKKwBLY9o5fkDakz2xFWBaE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777506480; c=relaxed/simple; bh=GFAzHbNwJu5mhtHEzS8CVBMhj66Od0WbqTAM3IWj3kE=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=t3eTx/8uq7Et6xUTt2zNLS7bv1LUMO6DYWQfygLAo9MIz2ZE+dSclobotx+WW0td00Z8ZTuBEz427zCn5sw4BEgoZhLEOD3yZ8ZWK1MHak97QoVqrp7+F+d+r2Y3eT176nb2n3RUJSrQSU9+0QceYVhsP0qenmsQavgwEJRjv0Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pSFmlhjj; 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="pSFmlhjj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81FD3C19425; Wed, 29 Apr 2026 23:47:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777506479; bh=GFAzHbNwJu5mhtHEzS8CVBMhj66Od0WbqTAM3IWj3kE=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From; b=pSFmlhjj9u16Xr17H4pyDLcKlCCQ8BbGdoO/6v5w24ztfHsIZnyr5QAPMoKV7J6wD drMXDxUPMKLrM0NAA21gAwlBwvfkPQ6m7QcMAf4hbtOHJHTJUo2CqvhB2F80BOX9nm BzcC84imGutxWfD6wog0byNp5xnXSaFzoXpsQ1GEXS9gwalZPkvZ+7wTm9hq9/en0t r48/9bZsV0v/6EbYIGuAWken+iksCdmr7gQU+z+A8e7P6lUrBA4yr00bein2sjfSZP tc+pX0WBWz3k2lXwZznLZAiswREnb8ZjbODVNH8q3+ZIvZlviHUKpGBxKJqN11eiHu sFNb5hg+uvn+Q== From: sashiko-bot@kernel.org Subject: Re: [v6 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: <20260429191431.2345448-9-bboscaccy@linux.microsoft.com> References: <20260429191431.2345448-9-bboscaccy@linux.microsoft.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2026 23:47:58 +0000 Message-Id: <20260429234759.81FD3C19425@smtp.kernel.org> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 4 potential issue(= s) to consider: - [Critical] Silent data corruption of the extracted eBPF payload due to un= quoted printf format string injection. - [Critical] Overly broad grep patterns in `extract-insn.sh` and `extract-m= ap.sh` cause payload duplication and severe corruption. - [High] Execution failure due to missing C preprocessor include paths. - [Medium] Bash scripting pitfalls: Incorrect exit code on failure, command= injection, and copy-paste error in usage. -- commit 398e95d4981b28182554e7639f02b8c22e6185c8 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. These payloads can then be used for signing a light skeleton binary using gen_sig. > diff --git a/scripts/hornet/extract-insn.sh b/scripts/hornet/extract-insn= .sh > new file mode 100755 > index 000000000000..52338f057ff6 > --- /dev/null > +++ b/scripts/hornet/extract-insn.sh > @@ -0,0 +1,27 @@ [ ... ] > +function usage() { > + echo "Sample script for extracting instructions" > + echo "autogenerated eBPF lskel headers" > + echo "" > + echo "USAGE: header_file" > + exit > +} Could this exit successfully (code 0) upon a usage error? Calling exit without an argument defaults to the exit status of the previous echo command, which is 0. If invoked incorrectly by a build system or Makefile, this might fail to halt the build process. This issue is also present in extract-map.sh and extract-skel.sh. [ ... ] > +if [ $ARGC -ne $EXPECTED_ARGS ] ; then > + usage > +else > + printf $(gcc -E $1 | grep "opts_insn" | \ > + awk -F"=3D" '{print $2}' | sed 's/;\+$//' | sed 's/\"//g') > +fi The autogenerated light skeletons explicitly include headers like . Since the script does not provide include paths (-I) to GCC or accept CFLAG= S, will the C preprocessor terminate with a fatal error if these headers are not present in the standard system include paths, resulting in an empty output file? Additionally, is it possible for the unquoted $1 to cause word-splitting or unintended command execution if a filename contains spaces or starts with a compiler flag? The grep pattern "opts_insn" appears to be overly broad. Could this match not only the target byte array but also structural assignments generated by bpftool, such as opts.insns_sz =3D sizeof(opts_insn) - 1? Because the extra code is unquoted, it would split into multiple arguments. When printf receives extra arguments without format specifiers, it repeated= ly reuses the format string, which in this case would cause it to duplicate and corrupt the eBPF binary payload output. Finally, since printf is called without a format specifier, could the extracted eBPF payload be silently corrupted? Bash's printf dynamically evaluates escapes. A byte sequence like \x25 (the % character) followed by \x73 (s) would be interpreted as %s and replaced with an empty string, or \x64 (d) to 0, silently altering the bytes and invalidating cryptographic signatures. Could this be prevented by using a format string like printf "%b" "$(...)"? The gcc include, unquoted $1, and printf issues are also present in extract-map.sh and extract-skel.sh. > diff --git a/scripts/hornet/extract-map.sh b/scripts/hornet/extract-map.sh > new file mode 100755 > index 000000000000..c309f505c623 > --- /dev/null > +++ b/scripts/hornet/extract-map.sh > @@ -0,0 +1,27 @@ [ ... ] > +function usage() { > + echo "Sample script for extracting instructions" This isn't a bug, but there is a copy-paste error in the usage message here. Should this say "extracting map data" instead of "extracting instructions"? [ ... ] > +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 Similar to extract-insn.sh, does the overly broad "opts_data" grep pattern also match extra struct assignments like opts.data_sz =3D sizeof(opts_data)= - 1 and cause payload duplication? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260429191431.2345= 448-1-bboscaccy@linux.microsoft.com?part=3D8