linux-kernel - [PATCH] genksyms: Duplicate function pointer type definitions segfault

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1437436369-46257-1-git-send-email-ryao@gentoo.org>
Date:	Mon, 20 Jul 2015 19:52:48 -0400
From:	Richard Yao <ryao@...too.org>
To:	linux-kernel@...r.kernel.org
Cc:	Richard Yao <richard.yao@...sterhq.com>,
	Madhuri Yechuri <madhuriyechuri@...sterhq.com>
Subject: [PATCH] genksyms: Duplicate function pointer type definitions segfault

From: Richard Yao <richard.yao@...sterhq.com>

I noticed that genksyms will segfault when it sees duplicate function
pointer type declaration when I placed the same function pointer
definition in two separate headers in a local branch as an intermediate
step of some refactoring. This can be reproduced by piping the following
minimal test case into `genksyms -r /dev/null` or alternatively, putting
it into a C file attempting a build:

int (*f)();
int (*f)();

Attaching gdb to genksyms to understand this failure is useless without
changing CFLAGS to emit debuginfo. Once you have debuginfo, you will
find that the failure is that `char *s` was NULL and the program
executed `while(*s)`. At which point, further debugging requires
familiarity with compiler front end / parser development.

What happens is that flex identifies the first instance of the token "f"
as IDENT and the yacc parser adds it to the symbol table. On the second
instance, flex will identify "f" as TYPE, which triggers an error case
in the yacc parser. Given that TYPE would have been IDENT had it not
been in the symbol table, the the segmentaion fault could be avoided by
treating TYPE as IDENT in the affected rule.

Some might consider placing identical function pointer type declarations
in different headers to be poor style might consider a failure to be
beneficial. However, failing through a segmentation fault makes the
cause non-obvious and can waste the time of anyone who encounters it.

Signed-off-by: Richard Yao <richard.yao@...sterhq.com>
Acked-by: Madhuri Yechuri <madhuriyechuri@...sterhq.com>
---
 scripts/genksyms/parse.y | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/scripts/genksyms/parse.y b/scripts/genksyms/parse.y
index b9f4cf2..723ab30 100644
--- a/scripts/genksyms/parse.y
+++ b/scripts/genksyms/parse.y
@@ -303,6 +303,15 @@ direct_declarator:
 		    $$ = $1;
 		  }
 		}
+	| TYPE
+		{ if (current_name != NULL) {
+		    error_with_pos("unexpected second declaration name");
+		    YYERROR;
+		  } else {
+		    current_name = (*$1)->string;
+		    $$ = $1;
+		  }
+		}
 	| direct_declarator '(' parameter_declaration_clause ')'
 		{ $$ = $4; }
 	| direct_declarator '(' error ')'
-- 
2.3.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/