Bug: SIGSEGV in OPENSSL_cleanse

John Keeping john at keeping.me.uk
Mon May 22 20:51:28 CEST 2017


On Mon, May 22, 2017 at 07:54:53PM +0200, Jan Jancar wrote:
> I am, or rather was, running an instance of cgit on an ARM box:
> 
> > uname -srm
> Linux 4.9.28-2-ARCH armv6l
> 
> I run ArchLinuxARM and they recently had an update to openssl:
> 
> openssl		1.1.0.e-1
> openssl-1.0	1.0.2.k-3
> 
> So I currently have 2 versions of openssl on that box.
> 
> After running cgit for awhile I noticed it now SIGSEGVs on certain requests:
> 
>            PID: 12517 (cgit.cgi)
>            UID: 33 (http)
>            GID: 33 (http)
>         Signal: 11 (SEGV)
>      Timestamp: Sun 2017-05-21 13:26:35 CEST (1 day 6h ago)
>   Command Line: /usr/lib/cgit/cgit.cgi
>     Executable: /usr/lib/cgit/cgit.cgi
>  Control Group: /system.slice/system-uwsgi.slice/uwsgi at cgit.service
>           Unit: uwsgi at cgit.service
>          Slice: system-uwsgi.slice
>        Boot ID: 93dadbde0e144f3ab346f1e21ac7ee5d
>     Machine ID: 4bd17fc498ad478094fa58c3a7782769
>       Hostname: Neuromancer
>        Storage:
> /var/lib/systemd/coredump/core.cgit\x2ecgi.33.93dadbde0e144f3ab346f1e21ac7ee5d.12517.1495365995000000000000.lz4
>        Message: Process 12517 (cgit.cgi) of user 33 dumped core.
> 
>                 Stack trace of thread 12517:
>                 #0  0x000000007678e7d8 OPENSSL_cleanse
> (/usr/lib/libcrypto.so.1.0.0)
> 
> 
> A bit more of the stack is shown when running the dump through gdb:
> 
> #0  0x765c37d8 in OPENSSL_cleanse () from /usr/lib/libcrypto.so.1.0.0
> #1  0x7664243c in EVP_MD_CTX_cleanup () from /usr/lib/libcrypto.so.1.0.0
> #2  0x76642774 in EVP_MD_CTX_destroy () from /usr/lib/libcrypto.so.1.0.0
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> 
> Investigating more, some weird behavior is shown, while ldd says
> cgit.cgi will run with /usr/lib/libcrypto.so.1.0.0 and even the coredump
> confirms that, when actually debugging the coredump, `info sharedlib` says:
> 
> warning: Corrupted shared library list: 0x76ffa8b0 != 0x0
> From        To          Syms Read   Shared Object Library
> 0x76fcf8f0  0x76feaaf0  Yes (*)     /lib/ld-linux-armhf.so.3
> 0x76e47000  0x76f6f794  Yes (*)     /usr/lib/libcrypto.so.1.1
> 0x76dcdb88  0x76dda8a0  Yes (*)     /usr/lib/libz.so.1
> 0x76da5190  0x76db6ce4  Yes (*)     /usr/lib/libpthread.so.0
> 0x76d8b7d0  0x76d8f418  Yes (*)     /usr/lib/librt.so.1
> 0x76d20580  0x76d74288  Yes (*)     /usr/lib/libluajit-5.1.so.2
> 0x76d09a30  0x76d0a944  Yes (*)     /usr/lib/libdl.so.2
> 0x76bd41f0  0x76cd4920  Yes (*)     /usr/lib/libc.so.6
> 0x76b3c680  0x76b776f0  Yes (*)     /usr/lib/libm.so.6
> 0x76b18180  0x76b26930  Yes         /usr/lib/libgcc_s.so.1
> 
> After that, setting LD_PRELOAD=/usr/lib/libcrypto.so.1.0
> actually fixes the problem. So is cgit incompatible with openssl 1.1
> or is there some other bug hiding?

Did you compile CGit yourself or are you using a pre-built package?
What version of libssl-dev is installed?

I wouldn't be surprised if compiling against openssl-1.0 headers but
linking with openssl-1.1 produces the behaviour you describe above.


More information about the CGit mailing list