After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 414301 - g_array_insert_vals segfaults on bad index or null array.
g_array_insert_vals segfaults on bad index or null array.
Status: RESOLVED DUPLICATE of bug 795975
Product: glib
Classification: Platform
Component: garray
2.12.x
Other All
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2007-03-03 17:05 UTC by Martin Vopatek
Modified: 2018-05-09 14:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Martin Vopatek 2007-03-03 17:05:37 UTC
Please describe the problem:
g_array_insert_vals(array,index,data,len) inserts len elements into a GArray at a given index. No check is made whether the index is actually outside of the current array length (array->len), which can lead to a segfault in g_memmove. Also, some functions in garray.c seem to check if the array is null and others do not.

I propose to add the following lines at the beginning of g_array_insert_vals
inspired by those found in g_array_remove_index:

g_return_val_if_fail (array != NULL, NULL);
g_return_val_if_fail (index <= array->len, NULL);

Steps to reproduce:
#include <glib.h>

int main(void)
{
    int value = 12345;
    GArray *array = NULL;

    array = g_array_new(FALSE, TRUE, sizeof(int));

    g_array_insert_val(array, 1, value);

    g_array_free(array, TRUE);
    return 0;
}

Actual results:
Results in a segmentation fault when a bad length value is sent to g_memmove in g_array_insert_vals. 

Expected results:
That the function g_array_insert_vals reports the error and returns a NULL pointer.

Does this happen every time?


Other information:
Comment 1 Philip Withnall 2018-05-09 14:38:51 UTC
This is going to be handled in bug #795975, which takes a slightly different approach (allowing the over-allocation). Thanks for the bug report!

*** This bug has been marked as a duplicate of bug 795975 ***