RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
Embargoed:

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
View All


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 781658 0 None None None 2019-07-11 20:13:24 UTC
GNOME Bugzilla 781716 0 None None None 2019-07-11 20:13:24 UTC
Red Hat Product Errata RHBA-2017:2100 0 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.