use-after-free in ivi controller when watched surface is deleted
Ucan, Emre (ADITG/SW1)
eucan at de.adit-jv.com
Thu Mar 17 04:11:36 EDT 2016
You are right about the double free, but I would prefer to remove the free call in content listener.
I will prepare a patch and send it today.
Thank you very much.
Software Group I (ADITG/SW1)
Tel. +49 5121 49 6937
> -----Original Message-----
> From: genivi-ivi-layer-management-bounces at lists.genivi.org [mailto:genivi-
> ivi-layer-management-bounces at lists.genivi.org] On Behalf Of Frederico
> Sent: Mittwoch, 16. März 2016 15:41
> To: genivi-ivi-layer-management at lists.genivi.org
> Subject: Bug: use-after-free in ivi controller when watched surface is deleted
> I noticed the following behavior in my setup that uses wayland-ivi-extension:
> - Application A is the HMI controller, using libilmControl
> - Application B is a client application that uses weston ivi shell directly
> - Application A watches registers to receive notifications on the surface
> of application B using ilm_surfaceAddNotification()
> Problem: when application B dies (e.g. segfaults) application A gets a
> segmentation fault from inside libilmControl.
> I have investigated and identified the root cause. What happens is that
> application A receives two events from the compositor:
> - one for the removal of the surface content,
> - another for the removal of the surface controller.
> See the corresponding code in 
> libilmControl has callbacks for both of these events, and in both cases
> it cleans up context_surface. Because the application has a notification
> and calls back into libilmControl, dispatch_event() is called again and
> starts processing the second event *before the first one is finished*
> When the stack unwinds, the cleanup is redone on the same structure and
> we have a read-after-free and double-free. Usually the read-after-free
> will include a NULL dereference but this actually depends on the state
> of the heap.
> See the abbreviated call stack from GDB. Please read bottom-up.
> //first cleanup here #0 controller_surface_listener_destroyed
> (data=0xb2e004e8, controller=<optimized out>)
> at /home/extra/git/wayland-ivi-extension-devtool/ivi-
> //process second event #4 0xb6586528 in dispatch_event
> (display=0xb2e004e8, queue=0x662c8) at /home/extra/git/wayland-
> //this causes dispatch #8 0xb6eb65b4 in impl_sync_and_acquire_instance
> (ctx=0xb6ec98f0 <ilm_context>) at /home/extra/git/wayland-ivi-extension-
> <application code calling back into libilmControl>
> //app calls into ilm #9 0xb6eb7c08 in ilm_layerSetRenderOrder (layerId=1,
> pSurfaceId=0x0, number=0) at /home/extra/git/wayland-ivi-extension-
> //call app cb #13 0xb6eb6110 in controller_surface_listener_content
> (data=0xb2e004e8, controller=0xb2e00578, content_state=8)
> //then cleanup again at /home/extra/git/wayland-ivi-extension-
> //first event #18 0xb65865b4 in dispatch_queue
> (display=display at entry=0x66b80, queue=queue at entry=0x662c8) at
> In attachment you will find a patch that I applied locally as a workaround
> to this issue.
> This was identified on a meta-ivi-9 environment (wayland-ivi-extension
> 1.3.0 and weston 1.6.0). But from my reading of the code the issue is still
> present on the master of wayland-ivi-extension.
> Could the developers advise if the anlysis and the patch are adequate?
> Best regards,
> : http://git.projects.genivi.org/?p=wayland-ivi-
> Frederico Cadete
> R&D Software Engineer
> VIT Software Development
> AWTC Europe - www.aweurope.eu - www.aisin-aw.co.jp
More information about the genivi-ivi-layer-management