GNOME Bugzilla – Bug 534077
Use of memory after free in e-cal-backend-sync.c
Last modified: 2008-05-23 10:31:14 UTC
Please describe the problem: While looking for another bug in LDAP (see bug #512605 ) with valgrind, I found this apparent bug (valgrind throws an error, for sure) in e-cal-backend-sync.c Steps to reproduce: 1. Run evolution-exchange-server under valgrind --tool=memcheck 2. Do some stuff with meeting invites/calendaring 3. Actual results: Got a report from valgrind as follows: ==00:01:24:45.071 18201== Invalid read of size 1 ==00:01:24:45.071 18201== at 0x4023A4F: strncmp (mc_replace_strmem.c:314) ==00:01:24:45.071 18201== by 0x4288507: icaltimezone_get_builtin_timezone_from_tzid (icaltimezone.c:1470) ==00:01:24:45.071 18201== by 0x807D111: set_default_timezone (e-cal-backend-exchange.c:1223) ==00:01:24:45.071 18201== by 0x41FD803: e_cal_backend_sync_set_default_zone (e-cal-backend-sync.c:549) ==00:01:24:45.071 18201== by 0x41FE93F: _e_cal_backend_set_default_zone (e-cal-backend-sync.c:958) ==00:01:24:45.071 18201== by 0x41F63F3: e_cal_backend_set_default_zone (e-cal-backend.c:1018) ==00:01:24:45.071 18201== by 0x41FFA00: impl_Cal_setDefaultTimezone (e-data-cal.c:479) ==00:01:24:45.071 18201== by 0x41EE6AE: _ORBIT_skel_small_GNOME_Evolution_Calendar_Cal_setDefaultTimezone (Evolution-DataServer-Calendar-common.c:96) ==00:01:24:45.071 18201== by 0x4DBF5C6: (within /usr/lib/libORBit-2.so.0.1.0) ==00:01:24:45.071 18201== by 0x4DC57B4: ORBit_OAObject_invoke (in /usr/lib/libORBit-2.so.0.1.0) ==00:01:24:45.071 18201== by 0x4DB290F: ORBit_small_invoke_adaptor (in /usr/lib/libORBit-2.so.0.1.0) ==00:01:24:45.071 18201== by 0x4DC3423: (within /usr/lib/libORBit-2.so.0.1.0) ==00:01:24:45.071 18201== Address 0x98653a8 is 0 bytes inside a block of size 44 free'd ==00:01:24:45.072 18201== at 0x402265C: free (vg_replace_malloc.c:323) ==00:01:24:45.072 18201== by 0x4285F59: icaltimezone_reset (icaltimezone.c:240) ==00:01:24:45.072 18201== by 0x4285F1A: icaltimezone_free (icaltimezone.c:229) ==00:01:24:45.072 18201== by 0x41FD770: e_cal_backend_sync_set_default_zone (e-cal-backend-sync.c:547) ==00:01:24:45.072 18201== by 0x41FE93F: _e_cal_backend_set_default_zone (e-cal-backend-sync.c:958) ==00:01:24:45.072 18201== by 0x41F63F3: e_cal_backend_set_default_zone (e-cal-backend.c:1018) ==00:01:24:45.072 18201== by 0x41FFA00: impl_Cal_setDefaultTimezone (e-data-cal.c:479) ==00:01:24:45.072 18201== by 0x41EE6AE: _ORBIT_skel_small_GNOME_Evolution_Calendar_Cal_setDefaultTimezone (Evolution-DataServer-Calendar-common.c:96) ==00:01:24:45.072 18201== by 0x4DBF5C6: (within /usr/lib/libORBit-2.so.0.1.0) ==00:01:24:45.072 18201== by 0x4DC57B4: ORBit_OAObject_invoke (in /usr/lib/libORBit-2.so.0.1.0) ==00:01:24:45.072 18201== by 0x4DB290F: ORBit_small_invoke_adaptor (in /usr/lib/libORBit-2.so.0.1.0) ==00:01:24:45.072 18201== by 0x4DC3423: (within /usr/lib/libORBit-2.so.0.1.0) Expected results: No reports from valgrind Does this happen every time? I'm not sure exactly which operation triggers this, but I do see multiple instances of this valgrind report. Other information:
Created attachment 111238 [details] [review] Proposed change to avoid using memory after free It seems that the tzid pointer points into the zone structure, so if you free zone before you set_default_zone_sync() then you access already-freed memory.
Commit to stable/trunk.
Patch committed to stable (gnome-2-22) branch as r8834 http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=8834 Patch committed to SVN trunk as r8835 http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=8835