"Wireshark crashes" is the newest contester for "worst bug report of all time".

Wireshark from debian testing on amd64: 1.12.0+git+4fab41a1-1
Can't reproduce with latest git.
Can't reproduce with cairo 1.12.16.
"NULL pointer dereference in cairo_image_surface_get_data()" sounds like the caller passed in a NULL pointer. That'd likely be a bug in the caller.

Is there someone who can reproduce this and tell us what actually happens? Thanks

You can't reproduce it with newer wireshark in Debian because a fix has already been applied to wireshark.

There is still potential for denial-of-service in other applications using cairo, and admittedly that's a lowish concern.

Ok, which fix? What's the bug in cairo? Could you please say more than "there is a bug"?

There are informative references at Mitre's site (see URL above).

Those references are "wireshark crashes if I do $THIS" (which I cannot reproduce), "the stack trace points at cairo, so this must be a bug in cairo" (which is just wrong) and you said "wireshark somehow worked around this", but apparently can't say how.

So those references can be summarized as "there is a bug. Somewhere.".

To explain why "the stack trace points at cairo, so this must be a bug in cairo" is just wrong, here is the code for cairo_image_surface_get_data(). Good luck spotting anything that depends on how much text someone enters into wireshark.

unsigned char *
cairo_image_surface_get_data (cairo_surface_t *surface)
{
    cairo_image_surface_t *image_surface = (cairo_image_surface_t *) surface;

    if (! _cairo_surface_is_image (surface)) {
	_cairo_error_throw (CAIRO_STATUS_SURFACE_TYPE_MISMATCH);
	return NULL;
    }

    return image_surface->data;
}

static inline cairo_bool_t
_cairo_surface_is_image (const cairo_surface_t *surface)
{
    return surface->backend && surface->backend->type == CAIRO_SURFACE_TYPE_IMAGE;
}

NULL pointer dereference in there means that the called passed in NULL, so the caller is wrong. I would suggest getting rid of that CVE (likely impossible) and reporting this to gtk+, since this being their bug seems the most likely to me. However, since apparently no one can reproduce this and wireshark devs are playing the finger-pointing-game, I would suggest forgetting about this.

Closing as INVALID. Feel free to reopen if there is some actually useful information about how those seven lines of code are buggy if I enter too much text somewhere.

I dont think this is a cairo bug, seems to be copy pasted what was in the crash report. Did some analysis found this

following code in simple_dialog.c , causes crash the argument ap is va_list (Variable Argument Lists) which is used when a function can accept any number of values, the number of arguments are unkown at compile time. putting 50,000 "A" s causes the corruption in va_list which lead to crash of program while executing the code

message = g_strdup_vprintf(msg_format, ap);

$17 = {_flags = 219, _IO_read_ptr = 0x7fc291d9f30e "g_strdup_vprintf", _IO_read_end = 0x7fc291d89188 "", _IO_read_base = 0x0, _IO_write_base = 0x0, _IO_write_ptr = 0x7fc291d86b38 "", _IO_write_end = 0x7fc291d9d829 "report_failure", _IO_buf_base = 0x7fc28dbc61f8 "", 
  _IO_buf_end = 0x7fc291d8f2d0 "\251\024", _IO_save_base = 0x500000000 <Address 0x500000000 out of bounds>, _IO_backup_base = 0x100000315 <Address 0x100000315 out of bounds>, _IO_save_end = 0x20 <Address 0x20 out of bounds>, _markers = 0x7fc28b541e80, _chain = 
    0x7fc291d894e0, _fileno = -1950316992, _flags2 = 32706, _old_offset = 140473647167928, _cur_column = 37256, _vtable_offset = -40 '\330', _shortbuf = "\221", _lock = 0x0, _offset = 3562113576, _codecvt = 0x5, _wide_data = 0x4512f0, _freeres_list = 0x0, _freeres_buf = 
    0x7fc2947ba9f0, _freeres_size = 140473670547440, _mode = -1848074240, _unused2 = "\302\177\000\000\360_\267\221\302\177\000\000\005\000\000\000\000\000\000"}

Submitting 50,000 A's into the the filter text box causes corruption scrambling the text on the Wireshark GUI this is because the va_list which stores all the strings are corrupted.