Summary: | app-crypt/pinentry-0.9.5 crashes with invalid pointer (not reproducible under gdb) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Renato Alves <simpledark> |
Component: | Current packages | Assignee: | Crypto team [DISABLED] <crypto+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alonbl, k_f, neal |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | https://bugs.gnupg.org/gnupg/issue2076 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
configure output
make output pinentry-gtk 0.9.5 pinentry-gtk 0.9.6 Valgrind logfile Valgrind logfile with track-origins=yes |
Description
Renato Alves
2015-09-10 16:56:53 UTC
Please follow bug#552614 comment#13 regarding nostrip. I did, but as said in the description, it didn't change the backtrace produced. Note that this is not a backtrace produced by gdb. It simply shows up on my terminal when the program crashes. I can't even redirect it to a file with &>file. Had to copy-paste from terminal. ok, so no gdb no symbols... difficult... maybe best to refine issue first... try 0.9.1...0.9.4 from[1], see where it breaks so we can diff the two versions. [1] http://mirrors.dotsrc.org/gcrypt/pinentry/ Created attachment 411564 [details]
configure output
Ok so I tried manual compiling them and 0.9.4 doesn't crash whereas 0.9.5 does. I also noticed this in the configure step: ... checking for GPG Error - version >= 1.16... yes (1.19) configure: WARNING: *** *** The config script /usr/bin/gpg-error-config was *** built for x86_64-pc-linux-gnu and thus may not match the *** used host x86_64-unknown-linux-gnu. *** You may want to use the configure option --with-gpg-error-prefix *** to specify a matching config script or use $SYSROOT. *** checking for libassuan-config... /usr/bin/libassuan-config checking for LIBASSUAN - version >= 2.1.0... yes (2.2.1) checking LIBASSUAN API version... okay configure: WARNING: *** *** The config script /usr/bin/libassuan-config was *** built for x86_64-pc-linux-gnu and thus may not match the *** used host x86_64-unknown-linux-gnu. *** You may want to use the configure option --with-libassuan-prefix *** to specify a matching config script. *** checking for byte typedef... no ... Tried to recompile these two libs but the configure error persisted as did the crash. Created attachment 411566 [details]
make output
Additionally, this seems to only affect the gtk backend. The curses interface works fine. x11-libs/gtk+ 2.24.28-r1 and 3.16.6 installed Also, about: checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu I'm not really sure where that is coming from given: # gcc-config -l [1] x86_64-pc-linux-gnu-4.8.5 * (In reply to Renato Alves from comment #7) > Additionally, this seems to only affect the gtk backend. The curses > interface works fine. > > x11-libs/gtk+ 2.24.28-r1 and 3.16.6 installed I'm having problems reproducing this, but it seems related to https://bugs.gnupg.org/gnupg/issue2076 so it is an upstream issue. That one seems specific to passphrases of a certain length, can you verify if this is the case for you as well (just generate a test key or try symmetric encryption) I just pushed pinentry 0.9.6 to ~arch. Can you please verify that the issue persists in this version? Upstream response: 23:03 < K_F> neal: fwiw, c.f https://bugs.gnupg.org/gnupg/issue2076 we have a fresh report at https://bugs.gentoo.org/show_bug.cgi?id=560158 if you need more user feedback for debugging 01:32 < neal> K_F: Thanks for the heads up! 01:33 < neal> neal: It might be worthwhile trying to run pinentry under valgrind 01:33 < neal> K_F: Since the reporter seems willing to help a git bisect would be very useful! Indeed it seems related. I just tried it and I managed to crash it in a different way. Steps to reproduce: 1. run pinentry (default gtk backend) 2. ask for pin (getpin) 3. in the GUI input 15 characters (I tried 15 zeros (0)) 4. input a 16th character. Pinentry crashes right away. The dump looks quite similar to the previous except the error was somewhere else: % pinentry OK Pleased to meet you getpin *** Error in `pinentry': realloc(): invalid pointer: 0x00007fe6225a5bc8 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x72c8f)[0x7fe62092cc8f] /lib64/libc.so.6(+0x780de)[0x7fe6209320de] /lib64/libc.so.6(realloc+0x26a)[0x7fe6209362fa] /usr/lib64/libglib-2.0.so.0(g_realloc+0xf)[0x7fe620f0721f] pinentry[0x40d317] /usr/lib64/libgobject-2.0.so.0(g_closure_invoke+0x138)[0x7fe621200338] ... Note that before the failure was on "free()" while now it's on "realloc()". ----- As for 0.9.6. I can't reproduce it there. It seems to work fine. I did notice a slight difference in the GUI elements used in 0.9.5 vs 0.9.6. Compare the following attachments. Created attachment 411946 [details]
pinentry-gtk 0.9.5
Created attachment 411948 [details]
pinentry-gtk 0.9.6
Given it seems fixed, is a git bisect still relevant? (In reply to Renato Alves from comment #15) > Given it seems fixed, is a git bisect still relevant? No, closing the bug as fixed in that case. Thanks for testing Glad to help. Cheers, Renato Hi Renato, Upstream here. Although the bug appears to be fixed in 0.9.6 (this might be because we changed from using our custom widget, which uses locked memory for storing the passphrase, to using standard widgets), I'm a bit worried that this bug might still be hiding somewhere. If you have time, I would greatly appreciate it if you could run a git bisect so that we can figure out where the bug was introduced! Thanks a lot! Neal Hi Neal, Could you provide the git repo URL. I can't seem to find it on the website, only tarball releases. I've tested tarballs before. 0.9.4 is good, 0.9.5 is bad, 0.9.6 is good again. Nevermind, got it. (In reply to Renato Alves from comment #20) > Nevermind, got it. Just in case anyone else wonder, for reference it is http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=summary Neal, so: git clone git://git.gnupg.org/pinentry.git ... 302903f76b8d62b1e07219a203f7219cb3aff7d8 is the first bad commit If this is relevant, this is what I have on the system: =dev-libs/libassuan-2.2.1 =dev-libs/libgpg-error-1.19 ----- On a side note, you may want to fix your configure.ac. I had to apply: diff --git a/configure.ac b/configure.ac index b71cb17..b458189 100644 --- a/configure.ac +++ b/configure.ac @@ -33,7 +33,7 @@ m4_define(mym4_version, [0.9.5]) # flag indicating a development version (mym4_isgit). Note that the # m4 processing is done by autoconf and not during the configure run. m4_define([mym4_revision], m4_esyscmd([git branch -v 2>/dev/null \ - | awk '/^\* / {printf "%s",$3}'])) + | awk '/^\* / {printf "%s",$8}'])) m4_define([mym4_revision_dec], m4_esyscmd_s([echo $((0x$(echo ]mym4_revision[|head -c 4)))])) m4_define([mym4_betastring], to temporarily workaround the following autogen.sh (strange) error during bisect: sh: 0xbran: value too great for base (error token is "0xbran") Basically, the awk expression is incorrect and will fail if the branchname has spaces. Which is true for bisect and detached HEADs. During bisect, git bisect -v returns: * (no branch, bisect started on 404943e) 302903f Remove internal mini-libassuan implementation and link to libassuan. master c64d1f4 Post release updates Anyway, have fun :) Hi Renato, I appreciate your quick response! Neal Hi Renato, I still can't reproduce the bug with the specified commit. Since you've build pinentry, you probably have debug symbols available. Could you try running pinentry under gdb and getting a backtrace and/or under valgrind? Thanks! Neal Hi Neal, So with gdb I get nothing as stated before. I can't crash it in the same way, so no traceback. With valgrind I got something right after typing in getpin<Return> . The error message is "Conditional jump or move depends on uninitialised value(s)" error. More on the attached logfile. Created attachment 412030 [details]
Valgrind logfile
Thanks! Can you rerun valgrind with --track-origins=yes, please? Also, when running under valgrind, you get the message after typing getpin<enter>, but before the dialog is shown? Is that correct? Does pinentry still crash when running under valgrind? Thanks! Created attachment 412034 [details]
Valgrind logfile with track-origins=yes
It looks kind of like half way through the widget creation. I see a window already but the widgets are not visible yet.
No it doesn't crash in valgrind either. Same as gdb.
And given the message in the logs, this is probably relevant:
% equery belongs /usr/lib64/libgtk-x11-2.0.so.0.2400.28
* Searching for /usr/lib64/libgtk-x11-2.0.so.0.2400.28 ...
x11-libs/gtk+-2.24.28-r1 (/usr/lib64/libgtk-x11-2.0.so.0.2400.28)
% equery belongs /usr/lib64/libgobject-2.0.so.0.4400.1
* Searching for /usr/lib64/libgobject-2.0.so.0.4400.1 ...
dev-libs/glib-2.44.1 (/usr/lib64/libgobject-2.0.so.0.4400.1)
|