Re: [Openvpn-users] v2.0 hangs

["James Yonan" <jim@xxxxxxxxx>]

Timo Sirainen <tss@xxxxxx> said:

> On 5.5.2004, at 23:07, Timo Sirainen wrote:
> 
> > c->c2.tls_multi looks garbage, so it's probably freed already? I could 
> > try running it with valgrind if it helps..

Aha!  You are right, there is a bug in close_instance() in 2.0-test26.

do_close_tls is executed first then do_close_remove_env, but the former closes
tls_multi while the latter references it under certain circumstances.

The fix is to rearrange the function ordering so do_close_remove_env gets
called before do_close_tls.

I will fix in the next 2.0 test release.

> Oh, that was easy.
> 
> ==3026== Conditional jump or move depends on uninitialised value(s)
> ==3026==    at 0x40269EAD: ssl3_get_finished (in 
> /usr/lib/i686/cmov/libssl.so.0.9.7)
> 1431)
> ==2945==    by 0x8056C17: close_instance (init.c:1638)
> ==2945==    by 0x805D366: tunnel_point_to_point (openvpn.c:87)
> ==2945==    by 0x805D5B7: main (openvpn.c:163)
> ==2945==  Address 0x41B3E398 is 272 bytes inside a block of size 1648 
> free'd
> ==2945==    at 0x4002F710: free (vg_replace_malloc.c:186)
> ==2945==    by 0x8056390: do_close_tls (init.c:1330)
> ==2945==    by 0x8056B95: close_instance (init.c:1625)
> ==2945==    by 0x805D366: tunnel_point_to_point (openvpn.c:87)
> ==2945==    by 0x805D5B7: main (openvpn.c:163)
> 
> do_close_tls() frees the multi but it's used after that. What's the 
> correct fix? :)
> 
> Valgrind showed a few others too:
> 
> ==3026== Conditional jump or move depends on uninitialised value(s)
> ==3026==    at 0x4002496B: strlen (mac_replace_strmem.c:162)
> ==3026==    by 0x804BA02: string_alloc (buffer.c:341)
> ==3026==    by 0x806E279: verify_callback (ssl.c:510)
> ==3026==    by 0x40322BE4: (within 
> /usr/lib/i686/cmov/libcrypto.so.0.9.7)
> 
> ==3026== Syscall param socketcall.sendto(msg) contains uninitialised or 
> unaddressable byte(s)
> ==3026==    at 0x40466456: __libc_sendto (in /lib/libc-2.3.2.so)
> ==3026==    by 0x805D3A1: tunnel_point_to_point (openvpn.c:81)
> ==3026==    by 0x805D5B7: main (openvpn.c:163)
> ==3026==  Address 0x41B417F6 is 98 bytes inside a block of size 1579 
> alloc'd
> ==3026==    at 0x4002EFF2: malloc (vg_replace_malloc.c:160)
> ==3026==    by 0x804B36A: alloc_buf (buffer.c:54)
> ==3026==    by 0x8068491: reliable_init (reliable.c:236)
> ==3026==    by 0x806F642: key_state_init (ssl.c:1106)
> ==3026==    by 0x806F957: tls_session_init (ssl.c:1216)
> ==3026==    by 0x806FD62: tls_multi_init_finalize (ssl.c:1361)
> ==3026==    by 0x8055863: do_init_finalize_tls_frame (init.c:947)
> ==3026==    by 0x8056A47: init_instance (init.c:1539)
> ==3026==    by 0x805D323: tunnel_point_to_point (openvpn.c:49)
> ==3026==    by 0x805D5B7: main (openvpn.c:163)
> 
> And lots of problems inside libcrypto. I'm not sure if they're real or 
> not.

These tend to look like false alarms.

James


____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users