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 47E14397B1C; Sun, 18 Oct 2026 16:05:43 +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=1792339545; cv=none; b=ExNBFVRZWt3kCu9lvjZ0v7KAQj9DR0cvmaD3VYlG5qbGnHudpr0xYn01uiTCPkgblQDolGHmRmhgbXm3scc24hQ26msVcwKjDtarG0NOo82yQSsJ1tT2viLC6hf4qKC7Jfazu5ZrPBbWQP9NfIWWOvTzPhspruf6+mCZHKXZ7Ss= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792339545; c=relaxed/simple; bh=I3mFYRlW1cJ+rcMolecnK2+xja8HIP1Uxg7ZuT8jr7s=; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type: Date; b=QoypQ9/qPRxyFyJXSAwqfAYNGiaAPmaLuElQEhRl7aDlU6EJ4FtG+hfcMf5urRDj0v6Uctr2iY8uzx59BigxLe5L9aXlc1FHisxS4ffnlhY17GZxIx9E/xaV94wNIuYACOMnZ0bXj+Ve9dMbHTVW/yNmZ+yfaaMohNUCi2vxq7s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ALyqpG/U; 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="ALyqpG/U" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B2FD1F000C4; Sun, 18 Oct 2026 16:05:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792339542; bh=Dj1iI/xVu8BjBO3XWtXsWJGOXPBDkz4MynJLZwJ+/n0=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=ALyqpG/UXqKELLjmI8iR9l2Q8+foCjR2CFD2+ei96Aw4z+Wnc55k5vML0FqHTHkVf RmKwzaFca8Pw9+u/aVGuyy4+QOOmeHMD94ZKUUd/erRIvVZE2LWJiGxX+RzRvVcRFa GT9gDGU71xFc482IpVgHD5MVEuxU+e0oCUIZfDCOCPgemwDRhSD7S6hB9LHv+YcbCO XIRKpvIDxbCR7pTwNZKrlr0BD6JNJ36V/ZvuKwVvMgAcM1gwS7cFFPHHadG1CYjUiP rICHf2D+r45Bt27Lr7QXujR17XPjMlm1DNx57chBLjcZOVDx56tJKKDlGtK7aYxb+Z w530UEkqaoPcA== Message-ID: From: sashiko-bot@kernel.org Subject: Re: [PATCH 14/15] kallsyms: scripts/kallsyms: Reduce the output file size Reply-To: sashiko-reviews@lists.linux.dev To: "David Laight" , "Andrew Morton" , "Petr Mladek" , "Kees Cook" , linux-kbuild@vger.kernel.org, bpf@vger.kernel.org, "Jim Cromie" , "Lorenzo Stoakes" Cc: "Luis Chamberlain" , "Andrey Grodzovsky" , "Steven Rostedt" , nathan@kernel.org, nsc@kernel.org In-Reply-To: <20261018155206.132411-15-david.laight.linux@gmail.com> References: <20261018155206.132411-1-david.laight.linux@gmail.com> <20261018155206.132411-15-david.laight.linux@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Oct 2026 16:05:41 +0000 Precedence: bulk X-Mailing-List: linux-kbuild@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [High] kallsyms: NULL dereference and offset mismatch in write_src() on u= nused tokens -- commit 20102d6e3b81d88a59f6ac3b9732c8a7b28d3f98 Author: David Laight kallsyms: scripts/kallsyms: Reduce the output file size This commit reduces the size of the assembly output generated by scripts/kallsyms by formatting byte values in decimal, packing multiple values per line for kallsyms_token_index and kallsyms_markers, moving the token tables first, and replacing duplicate symbol name comments with symbol offsets. > diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c > index 189fb50ec8c58..8576fe6ad90b7 100644 > --- a/scripts/kallsyms.c > +++ b/scripts/kallsyms.c > @@ -350,6 +350,30 @@ static void write_src(void) > struct sym_entry *se; > =20 > printf("\t.section .rodata, \"a\"\n"); > + printf("\n"); > + > + output_label("kallsyms_token_table"); > + off =3D 0; > + for (i =3D 0; i < 256; i++) { > + best_idx[i] =3D off; > + off +=3D token_table[i].len + 1; > + printf("\t.asciz\t\"%s\"\t/* %u: %u */\n", > + token_table[i].str, i, token_table[i].refs); > + } [Severity: High] Can token_table[i].str be NULL here when fewer than 256 tokens are populated? During pass 0 of a CONFIG_KALLSYMS=3Dy build, scripts/link-vmlinux.sh runs scripts/kallsyms on an empty symbol file: scripts/link-vmlinux.sh:kallsyms_step() { ... if is_enabled CONFIG_KALLSYMS; then true > .tmp_vmlinux0.syms kallsyms .tmp_vmlinux0.syms .tmp_vmlinux0.kallsyms fi ... } When symbol_cnt is 0 (or whenever the input symbols do not populate all 256 entries), insert_real_symbols_in_table() leaves token_table[i].str as NULL and token_table[i].len as 0 for unreferenced tokens: scripts/kallsyms.c:insert_real_symbols_in_table() { ... for (i =3D 0; i <=3D 255; i++) { if (!token_table[i].refs) continue; token_table[i].len =3D 1; token_table[i].str =3D xmalloc(2); token_table[i].str[0] =3D i; token_table[i].str[1] =3D 0; } } In optimize_result(), find_best_token() then returns -1 and breaks out of the loop before filling the remaining unused tokens. When write_src() passes token_table[i].str to printf("%s"), isn't that undefined behavior that segfaults on non-glibc hosts (such as musl)? Also, on glibc hosts where printf("%s", NULL) outputs "(null)" (7 bytes including the NUL terminator in .asciz), off is only incremented by token_table[i].len + 1 (1 byte), which mismatches the actual size emitted into kallsyms_token_table and corrupts the offsets recorded in best_idx[]. [ ... ] --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261018155206.1324= 11-1-david.laight.linux@gmail.com?part=3D14