1282281 - FMR: reading of freed memory in gdk_event_apply_filters

Status: NEW

(Core :: Widget: Gtk, defect, P4)

Description

[Julian Seward [:jseward]]

This occurs with m-c (trunk) on Fedora 23 on x86_64.  It also occurred
with Fedora 21.  I had assumed it was a bug in the GTK shipped in
Fedora 21, but now I am mystified why something so obvious didn't get
fixed by the time Fedora 23 came around.  I still think it's a GTK bug
but I don't really know, so I am filing it here to see if anyone else
knows anything about it, or has seen it before.

STR: do a --enable-valgrind --disable-jemalloc build, then:

DISPLAY=:1.0 ./mach mochitest -f plain --keep-open=false \
  --valgrind=vTRUNK \
  --valgrind-args=--show-mismatched-frees=no,--num-callers=40 \
  dom/plugins/test/mochitest 2>&1 | tee spew-02-08-mc

It reproduces reliably, although the above does take about five
minutes to run.

Comment 1

[Julian Seward [:jseward]]

Attachment: valgrind complaint

Comment 2

[Julian Seward [:jseward]]

Looking at gtk+-3.18.9/gdk/x11/gdkeventsource.c, gdk_event_apply_filters()
and comparing against the invalid-read stack and the where-it-was-freed stack,
we see this fragment

81    result = filter->function (xevent, event, filter->data);
82
83    /* Protect against unreffing the filter mutating the list */
84    node = tmp_list->next;

The block is freed by the call at line 81 but then read from at 84.
From the comment it seems that someone has already considered the
possibility that bad things might happen if the list is modified whilst
it is being traversed.

A bit of googling leads to this, which seems related:

 https://mail.gnome.org/archives/commits-list/2015-February/msg03748.html

and the associated bug

 https://bugzilla.gnome.org/show_bug.cgi?id=635380

but inspection of the relevant patch seems to suggest that it has long
since been folded into the 3.18.9 sources, at least for
gdk_event_apply_filters() -- although the source of the latter has
clearly changed quite a bit since then.

So I don't understand what is going on.  Is this perhaps a residual GTK
bug?  Or are we misusing GTK somehow?

Comment 3

[Karl Tomlinson (back June 29 :karlt)]

(In reply to Julian Seward [:jseward] from comment #2)
> Is this perhaps a residual GTK bug?

I think so.  Reported https://bugzilla.gnome.org/show_bug.cgi?id=768078

Comment 4

[Julian Seward [:jseward]]

Karl, thank you for looking at it and for filing the Gnome bug.  Since
it may be some time before this is fixed upstream and finds its way
downstream, is there anything we can do on our side to avoid this problem?

Comment 5

[Karl Tomlinson (back June 29 :karlt)]

It may be possible to intercept DestroyNotify on these windows and remove the filter at a time that works out better, but I guess the function of _gtk_socket_windowing_filter_func would need to be replicated.

Such workarounds depend on the precise GTK implementation, and so are less risky once the bug has been fixed in GDK.  That allows us to limit the workaround to older affected versions where we know the code that we are messing with.

Any effort should be first spent fixing the GDK bug.