Optimization-dependent behavior with GnuPG 1.4.19 and GCC 5
gniibe at fsij.org
Thu Oct 1 07:21:17 CEST 2015
Thank you for the bug report with reproducible scenario.
On 09/30/2015 04:16 PM, Kevin Locke wrote:
> Debugging the behavior in gdb shows that in parse_signature at
> g10/parse-packet.c:1413, sig->unhashed is NULL. This results in
> taking the branch at g10/parse-packet.c:1185 in enum_sig_subpkt which
> returns the address of the pktbuf argument. Although the code expects
> this to result in a non-NULL value, it appears that the compiler
> optimizations at -O2 result in returning a NULL value. I'm unsure if
> this is a compiler error, or if this is allowed as undefined behavior
> when using the address of an argument after a function has returned.
Your analysis is correct. I think it's up to compiler.
> Thoughts? Is anyone else seeing this behavior?
I confirmed this bug in my Debian machine.
We have a fix for master branch. I'm going to backport this to 2.0
Author: Werner Koch <wk at gnupg.org>
Date: Thu Sep 18 15:08:51 2014 +0200
gpg: Silence a compiler warning.
* g10/parse-packet.c (enum_sig_subpkt): Replace hack.
diff --git a/g10/parse-packet.c b/g10/parse-packet.c
index edaa84d..f7b2079 100644
@@ -1428,11 +1428,10 @@ enum_sig_subpkt (const subpktarea_t * pktbuf, sigsubpkttype_t reqtype,
if (!pktbuf || reqseq == -1)
- /* return some value different from NULL to indicate that
- * there is no critical bit we do not understand. The caller
- * will never use the value. Yes I know, it is an ugly hack */
- return reqtype ==
- SIGSUBPKT_TEST_CRITICAL ? (const byte *) &pktbuf : NULL;
+ static char dummy = "x";
+ /* Return a value different from NULL to indicate that
+ * there is no critical bit we do not understand. */
+ return reqtype == SIGSUBPKT_TEST_CRITICAL ? dummy : NULL;
buffer = pktbuf->data;
buflen = pktbuf->len;
More information about the Gnupg-devel