Re: read after free in notmuch new

Subject:Re: read after free in notmuch new

Date:Mon, 20 Feb 2017 22:46:11 -0400

To:notmuch@notmuchmail.org

Cc:

From:David Bremner


David Bremner <david@tethera.net> writes:

> David Bremner <david@tethera.net> writes:
>
>> I haven't had a chance to really track this down, but it seems there is
>> a memory error in notmuch new (or a maybe false positive from valgrind).
>>
>> Attached is the log from running "make memory-test OPTIONS=--medium" on
>> current git master (0e037c34).
>>
>> It looks like we talloc the message_id string with the message object as
>> parent, but it somehow outlives the message object.
>
> Sorry, that had a few commits beyond master.
>
> master (08343d3d) gives essentially the same log.
>

The log says the relevent piece of memory was freed at line 655 of database.cc, which
is the g_hash_table_insert in the code 

	ref = _parse_message_id (ctx, refs, &refs);

	if (ref && strcmp (ref, message_id)) {
	    g_hash_table_insert (hash, ref, NULL);
	    last_ref = ref;
	}


According to the docs for g_hash_table_insert

   If the key already exists in the GHashTable its current value is
   replaced with the new value. If you supplied a value_destroy_func
   when creating the GHashTable, the old value is freed using that
   function. If you supplied a key_destroy_func when creating the
   GHashTable, the passed key is freed using that function.

Since we do pass a key_destroy_func, it seems we are being naughty by
returning last_ref just below.

I'm not sure about the best solution; one option would be to drop the
key_destroy_func and manually talloc_free ref, something like

    char *ref=NULL;

     while (*refs) {
        if (ref) talloc_free (ref);
        ref = _parse_message_id (ctx, refs, &refs);

	if (ref && strcmp (ref, message_id)) {
	    g_hash_table_insert (hash, ref, NULL);
	    last_ref = ref;
	}
     }

Thread: