Bug 1444490

Summary: Invalid write of size 8
Product: Red Hat Enterprise Linux 7 Reporter: Milan Crha <mcrha>
Component: at-spi2-atkAssignee: Rui Matos <rmatos>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: jkoten, modehnal, tpelka, vbenes
Target Milestone: rcKeywords: TestBlocker
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: at-spi2-atk-2.22.0-2.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-01 12:30:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1444405    
Attachments:
Description Flags
proposed patch
none
proposed patch - issue ][ none

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