Bug 1444490 - Invalid write of size 8
Summary: Invalid write of size 8
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: at-spi2-atk
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Rui Matos
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1444405
TreeView+ depends on / blocked
 
Reported: 2017-04-21 12:45 UTC by Milan Crha
Modified: 2017-08-01 12:30 UTC (History)
4 users (show)

Fixed In Version: at-spi2-atk-2.22.0-2.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 12:30:39 UTC
Target Upstream Version:


Attachments (Terms of Use)
proposed patch (608 bytes, patch)
2017-04-21 13:07 UTC, Milan Crha
no flags Details | Diff
proposed patch - issue ][ (2.69 KB, patch)
2017-04-25 10:36 UTC, Milan Crha
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
GNOME Bugzilla 781658 None None None 2019-07-11 20:13:24 UTC
GNOME Bugzilla 781716 None None None 2019-07-11 20:13:24 UTC
Red Hat Product Errata RHBA-2017:2100 normal SHIPPED_LIVE GTK+ bug fix update 2017-08-01 16:06:50 UTC

Description Milan Crha 2017-04-21 12:45:25 UTC
While trying to figure out bug #1444405 I noticed under valgrind an invalid write from atk-spi, which can cause the error in bug #1444405, due to overwriting memory which is not its.

This is with:
glib2-2.50.3-2.el7.x86_64
gtk3-3.22.10-3.el7.x86_64
evolution-3.22.6-8.el7.x86_64
atk-2.22.0-1.el7.x86_64
at-spi2-atk-2.22.0-1.el7.x86_64
dbus-1.6.12-17.el7.x86_64


Steps:
a) have enabled accessibility in the system + enable also Screen reader
b) open terminal and run from there:
   $ G_SLICE=always-malloc valgrind evolution
c) once evolution opens, click the New button, which opens the composer
d) once composer is there, switch back to evolution and close it

That's the moment when the below valgrind log shows up. To make it clear, the composer window is still there, it's only the main window of Evolution which had been closed.

As this is invalid write, it overwrites some "random" chunk of 8 bytes in memory, effectively causing memory corruption in whatever place the memory got occupied with. Such things are hard to reproduce, but it seems the test from bug #1444405 can reproduce the crash consistently when run under behave. I see the valgrind log consistently too, but it doesn't break things always, especially when not run under valgrind.

==2809== Thread 1:
==2809== Invalid write of size 8
==2809==    at 0x18FCF001: remove_events (bridge.c:759)
==2809==    by 0x18FCF001: handle_event_listener_deregistered (bridge.c:788)
==2809==    by 0x18FCF001: signal_filter (bridge.c:827)
==2809==    by 0x200ECDFD: dbus_connection_dispatch (dbus-connection.c:4631)
==2809==    by 0x1FEBD0F4: ??? (in /usr/lib64/libatspi.so.0.0.1)
==2809==    by 0xFD8D4C8: g_main_dispatch (gmain.c:3201)
==2809==    by 0xFD8D4C8: g_main_context_dispatch (gmain.c:3854)
==2809==    by 0xFD8D817: g_main_context_iterate.isra.21 (gmain.c:3927)
==2809==    by 0xFD8DAE9: g_main_loop_run (gmain.c:4123)
==2809==    by 0xDFF84B4: gtk_main (in /usr/lib64/libgtk-3.so.0.2200.10)
==2809==    by 0x403DE0: main (in /usr/bin/evolution)
==2809==  Address 0x29f22540 is 16 bytes inside a block of size 24 free'd
==2809==    at 0x4C2ACDD: free (vg_replace_malloc.c:530)
==2809==    by 0xFD92BCD: g_free (gmem.c:189)
==2809==    by 0xFDAA518: g_slice_free1 (gslice.c:1136)
==2809==    by 0xFD89463: g_list_remove (glist.c:521)
==2809==    by 0x18FCF000: remove_events (bridge.c:759)
==2809==    by 0x18FCF000: handle_event_listener_deregistered (bridge.c:788)
==2809==    by 0x18FCF000: signal_filter (bridge.c:827)
==2809==    by 0x200ECDFD: dbus_connection_dispatch (dbus-connection.c:4631)
==2809==    by 0x1FEBD0F4: ??? (in /usr/lib64/libatspi.so.0.0.1)
==2809==    by 0xFD8D4C8: g_main_dispatch (gmain.c:3201)
==2809==    by 0xFD8D4C8: g_main_context_dispatch (gmain.c:3854)
==2809==    by 0xFD8D817: g_main_context_iterate.isra.21 (gmain.c:3927)
==2809==    by 0xFD8DAE9: g_main_loop_run (gmain.c:4123)
==2809==    by 0xDFF84B4: gtk_main (in /usr/lib64/libgtk-3.so.0.2200.10)
==2809==    by 0x403DE0: main (in /usr/bin/evolution)
==2809==  Block was alloc'd at
==2809==    at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
==2809==    by 0xFD92ABD: g_malloc (gmem.c:94)
==2809==    by 0xFDA9EFD: g_slice_alloc (gslice.c:1025)
==2809==    by 0xFD89983: g_list_append (glist.c:261)
==2809==    by 0x18FCE7EE: add_event (bridge.c:80)
==2809==    by 0x18FCE7EE: add_event_from_iter (bridge.c:217)
==2809==    by 0x18FCEEF6: handle_event_listener_registered (bridge.c:721)
==2809==    by 0x18FCEEF6: signal_filter (bridge.c:825)
==2809==    by 0x200ECDFD: dbus_connection_dispatch (dbus-connection.c:4631)
==2809==    by 0x1FEBD0F4: ??? (in /usr/lib64/libatspi.so.0.0.1)
==2809==    by 0xFD8D4C8: g_main_dispatch (gmain.c:3201)
==2809==    by 0xFD8D4C8: g_main_context_dispatch (gmain.c:3854)
==2809==    by 0xFD8D817: g_main_context_iterate.isra.21 (gmain.c:3927)
==2809==    by 0xFD8DAE9: g_main_loop_run (gmain.c:4123)
==2809==    by 0xDFF84B4: gtk_main (in /usr/lib64/libgtk-3.so.0.2200.10)

Comment 2 Milan Crha 2017-04-21 13:07:15 UTC
Created attachment 1273320 [details]
proposed patch

This fixed the valgrind claim to me.

Comment 3 Rui Matos 2017-04-24 12:55:33 UTC
(In reply to Milan Crha from comment #2)
> Created attachment 1273320 [details]
> proposed patch
> 
> This fixed the valgrind claim to me.

Thank you for the patch. I filed a cleaner version upstream, can you confirm it fixes the crashes for you?

Comment 4 Milan Crha 2017-04-24 16:25:33 UTC
It doesn't fix the crash from the other bug report (see comment #0), but it does fix the valgrind claim. Thanks.

Comment 5 Milan Crha 2017-04-25 10:36:03 UTC
Created attachment 1273870 [details]
proposed patch - issue ][

Could you include also this patch, please? It fixes some other possible use-after-free issues in the package. It seems that not all code expects atk_object_ref_accessible_child() returning NULL, neither that it can return an object with only one reference, thus the following unref can cause use-after-free eventually.

At least the chunk in impl_GetChildAtIndex() avoids runtime warning about invalid object being passed to g_object_unref(), which happened, in this case, when evolution returned NULL. Evolution returns objects with one reference only often, which tries to address the other chunks here.

Comment 6 Milan Crha 2017-04-25 13:41:27 UTC
Upstream bug for the second issue:
https://bugzilla.gnome.org/show_bug.cgi?id=781716

Comment 9 Michal Odehnal 2017-05-31 11:44:29 UTC
No longer reproducible.

Comment 10 errata-xmlrpc 2017-08-01 12:30:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2100


Note You need to log in before you can comment on or make changes to this bug.