Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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)
(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?
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.
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