openvpn assert failure: *** Error in `/usr/sbin/openvpn': malloc(): smallbin double linked list corrupted: 0x00007fa766e09fb0 ***

Bug #1406220 reported by Sora Celestinia
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
openvpn (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

ProblemType: Crash
DistroRelease: Ubuntu 14.04
Package: openvpn 2.3.2-7ubuntu3.1
ProcVersionSignature: Ubuntu 3.13.0-43.72-lowlatency 3.13.11.11
Uname: Linux 3.13.0-43-lowlatency x86_64
ApportVersion: 2.14.1-0ubuntu3.6
Architecture: amd64
AssertionMessage: *** Error in `/usr/sbin/openvpn': malloc(): smallbin double linked list corrupted: 0x00007fa766e09fb0 ***
Date: Tue Dec 23 11:57:37 2014
ExecutablePath: /usr/sbin/openvpn
ExecutableTimestamp: 1417473095
InstallationDate: Installed on 2014-04-27 (240 days ago)
InstallationMedia: Ubuntu-Studio 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.3)
ProcCmdline: /usr/sbin/openvpn
ProcCwd: /
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
 LANG=en_US.UTF-8
Signal: 6
SourcePackage: openvpn
StacktraceTop:
 __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7fa764f4b5a8 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
 malloc_printerr (action=<optimized out>, str=0x7fa764f4b970 "malloc(): smallbin double linked list corrupted", ptr=<optimized out>) at malloc.c:4996
 _int_malloc (av=0x7fa765188760 <main_arena>, bytes=72) at malloc.c:3359
 __GI___libc_malloc (bytes=72) at malloc.c:2891
 ?? ()
Title: openvpn assert failure: *** Error in `/usr/sbin/openvpn': malloc(): smallbin double linked list corrupted: 0x00007fa766e09fb0 ***
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

Revision history for this message
Sora Celestinia (celestinia) wrote :
information type: Private → Public
description: updated
Revision history for this message
Apport retracing service (apport) wrote :

StacktraceTop:
 __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7fa764f4b5a8 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
 malloc_printerr (action=<optimized out>, str=0x7fa764f4b970 "malloc(): smallbin double linked list corrupted", ptr=<optimized out>) at malloc.c:4996
 _int_malloc (av=0x7fa765188760 <main_arena>, bytes=72) at malloc.c:3359
 __GI___libc_malloc (bytes=72) at malloc.c:2891
 gc_malloc (size=size@entry=64, clear=clear@entry=false, a=a@entry=0x7fffc95a36c0) at buffer.c:336

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : StacktraceSource.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in openvpn (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
information type: Public → Private Security
information type: Private Security → Private
information type: Private → Private Security
description: updated
information type: Private Security → Public
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openvpn (Ubuntu):
status: New → Confirmed
Revision history for this message
Joshua Cannell (jcannell) wrote :

I often encounter this bug...would be nice to get it fixed.

Revision history for this message
Paul Crawford (psc-sat) wrote :

It might be appearing now as Bug #1577433 due to some change in malloc() reporting text. I also see this and would like it fixed as memory allocation bugs in OpenVPN are potential security vulnerabilities.

Revision history for this message
Paul Crawford (psc-sat) wrote :

Forgot to add the system details:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty

$ apt-cache policy openvpn
openvpn:
  Installed: 2.3.2-7ubuntu3.1
  Candidate: 2.3.2-7ubuntu3.1
  Version table:
 *** 2.3.2-7ubuntu3.1 0
        500 http://gb.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
        100 /var/lib/dpkg/status
     2.3.2-7ubuntu3 0
        500 http://gb.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Download full text (3.3 KiB)

Hi,
This came up by our checker for bug inactivity and I beg (all) your pardon, but to action on this is hard without a way to reproduce.

All the fail on the stacktrace top are irrellevant as it is the (mis)-usage by openvpn we would have to spot and that is rather down the trace.

Comparing the linked and the stacktrace here show that they seem not to be the same.
This one here is while initializing a tunnel instance and the following cleanup that fails on freeing resources.
#9 0x00007fa766263f57 in do_close_tun (c=c@entry=0x7fffc95a38d0, force=force@entry=false) at init.c:1546
        tuntap_actual = 0x7fa766df4228 "tun0"
        local = 168305898
        remote_netmask = 168305897
        gc = {list = 0x7fa766df4220}
#10 0x00007fa7662674f3 in close_instance (c=c@entry=0x7fffc95a38d0) at init.c:3512
No locals.
#11 0x00007fa7662679a8 in close_context (c=c@entry=0x7fffc95a38d0, sig=sig@entry=-1, flags=flags@entry=4) at init.c:3687
No locals.
#12 0x00007fa76626863a in init_instance (c=c@entry=0x7fffc95a38d0, env=env@entry=0x7fa766de6a38, flags=flags@entry=4) at init.c:3473
        options = 0x7fffc95a38d0
        child = false
        link_socket_mode = <optimized out>
#13 0x00007fa766269250 in init_instance_handle_signals (c=0x7fffc95a38d0, env=0x7fa766de6a38, flags=4) at init.c:3233
No locals.

While the linked bug in the crash tracker close but more around freeing a key schedule including the openssl bits:
#20 0x00005583969a4586 in tls_ctx_free (ctx=ctx@entry=0x7ffc77eb8170) at ssl_openssl.c:141
No locals.
#21 0x0000558396957528 in key_schedule_free (ks=ks@entry=0x7ffc77eb8138, free_ssl_ctx=<optimized out>) at init.c:1933
No locals.
#22 0x000055839695a567 in do_close_free_key_schedule (free_ssl_ctx=<optimized out>, c=0x7ffc77eb7980) at init.c:2819
No locals.
#23 close_instance (c=c@entry=0x7ffc77eb7980) at init.c:3506
No locals.
#24 0x000055839695ab08 in close_context (c=c@entry=0x7ffc77eb7980, sig=sig@entry=-1, flags=flags@entry=4) at init.c:3687
No locals.
#25 0x000055839695b79a in init_instance (c=c@entry=0x7ffc77eb7980, env=env@entry=0x5583982c9ba8, flags=flags@entry=4) at init.c:3473
        options = 0x7ffc77eb7980
        child = false
        link_socket_mode = <optimized out>

They go down very different paths, free different ressources and therefore seem not directly related to me. Of course they could be of the same root cause being a mem overwrite, but it is not confirm-able right now.

The only good thing I can see here is that the auto reported crash ceased to show up since Xenial. Yet it could as well just have changed it's signature to be detected as the same issue.

I have read through the code a bit but nothing obvious stood out, so without better debugging I can't try to fix. Since it might have been fixed in a latter version as indicated by the crash report I checked the git repo, but there was no change directly pointing to this or similar issues that I considerd having a high chance and worth a try.

As bad as the issue is - unless one is willing to read, read, read code with a high chance to still not find anything what really would be needed is a reliable reproducer.
Like configure it like A,B,C and then run D whi...

Read more...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.