Re: [PATCH v3 1/6] genksyms: fix infinite loop on declarations with parameter lists

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] genksyms: unresolvable ambiguous 12-char SHA in Fixes trailer
--

commit e896d8ddfccae8b5749722baf42845ecf75f09be
Author: Leizhen Zhang <lzsx618@gmail.com>

> genksyms: fix infinite loop on declarations with parameter lists
>
> decl_specifier_seq updates the global decl_spec, which is used by the ','
> action of init_declarator_list to give each further declarator the
> specifiers of the declaration. However, decl_specifier_seq is also used
> for parameter declarations, so for a declaration such as
>
>   int a, f(int);
>
> decl_spec is clobbered by the specifiers of the parameter "int" by the
> time the ',' action runs. The action then links the parameter's own token
> node back into its chain, creating a cycle, and copy_list_range() loops
> forever while allocating memory:
>
>   $ printf 'int a, f(int);\n' | scripts/genksyms/genksyms
>   (hangs)
>
> Before commit 45c9c4101d3d ("genksyms: fix memory leak when the same
> symbol is added from source") the same corruption did not hang but
> silently recorded a wrong type for subsequent declarators (e.g. for
> "int f(long), a;" the type of "a" was recorded as "int f ( long a").
>
> Only set decl_spec in decl_specifier_seq_opt, which is used at the
> declaration level, and let decl_specifier_seq just return the last
> specifier. Struct and union member declarations use a new
> member_decl_specifier_seq_opt that does not touch decl_spec, so a
> struct body nested in a parameter list cannot clobber it either.
>
> The generated symtypes and CRCs for 149 preprocessed kernel source files
> (1128 exported symbols) are unchanged, and no new bison conflicts are
> introduced.
>
> Found by fuzzing genksyms with ASan/UBSan.
>
> The problem was found with ASan and UBSan, and the analysis and fix were
> prepared with the help of an AI coding assistant; I reviewed and
> tested the result.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Leizhen Zhang <lzsx618@gmail.com>

[Severity: Low]
In the kernel repository, the 12-character prefix 1da177e4c3f4 is ambiguous
because it matches both 1da177e4c3f41 ("Linux-2.6.12-rc2") and
1da177e4c3f47 ("docs: git SHA prefixes are for humans"), so git cannot
resolve the Fixes tag.  Should this use at least 13 characters, or
reference 45c9c4101d3d ("genksyms: fix memory leak when the same symbol is
added from source") which introduced the copy_list_range() call that loops
forever?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110000003.1719966-1-lzsx618@gmail.com?part=1