[PATCH 2/9] genksyms: fix infinite loop on declarations with parameter lists
From: lzhan011
Date: Mon Oct 05 2026 - 06:47:10 EST
From: lzhan011 <zhangleizhen645@xxxxxxxxx>
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.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Assisted-by: Claude:claude-opus-5-5 ASan UBSan
Signed-off-by: lzhan011 <zhangleizhen645@xxxxxxxxx>
---
scripts/genksyms/parse.y | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/scripts/genksyms/parse.y b/scripts/genksyms/parse.y
index cabcd146f..7cc0336a7 100644
--- a/scripts/genksyms/parse.y
+++ b/scripts/genksyms/parse.y
@@ -201,13 +201,28 @@ init_declarator:
/* Hang on to the specifiers so that we can reuse them. */
decl_specifier_seq_opt:
/* empty */ { decl_spec = NULL; }
+ | decl_specifier_seq { decl_spec = *$1; }
+ ;
+
+/*
+ * Unlike decl_specifier_seq_opt, this does not touch decl_spec, so that
+ * a struct/union body nested in a parameter list does not clobber the
+ * specifiers of the enclosing declaration.
+ */
+member_decl_specifier_seq_opt:
+ /* empty */ { $$ = NULL; }
| decl_specifier_seq
;
+/*
+ * Do not set decl_spec here; decl_specifier_seq is also used for parameter
+ * declarations, which would clobber the specifiers of the enclosing
+ * declaration, e.g. "int a, f(long);".
+ */
decl_specifier_seq:
- attribute_opt decl_specifier { decl_spec = *$2; }
- | decl_specifier_seq decl_specifier { decl_spec = *$2; }
- | decl_specifier_seq ATTRIBUTE_PHRASE { decl_spec = *$2; }
+ attribute_opt decl_specifier { $$ = $2; }
+ | decl_specifier_seq decl_specifier { $$ = $2; }
+ | decl_specifier_seq ATTRIBUTE_PHRASE { $$ = $2; }
;
decl_specifier:
@@ -456,7 +471,7 @@ member_specification:
;
member_declaration:
- decl_specifier_seq_opt member_declarator_list_opt ';'
+ member_decl_specifier_seq_opt member_declarator_list_opt ';'
{ $$ = $3; dont_want_type_specifier = false; }
| error ';'
{ $$ = $2; dont_want_type_specifier = false; }
--
2.34.1