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


Hi Frederico,

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.

Best regards

Emre Ucan
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
> Cadete
> 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
> 
> Hello,
> 
> 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 [1]
> 
> 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-
> layermanagement-api/ilmControl/src/ilm_control_wayland_platform.c:728
>                            ...
>     //process second event #4  0xb6586528 in dispatch_event
> (display=0xb2e004e8, queue=0x662c8) at /home/extra/git/wayland-
> devtool/src/wayland-client.c:1150
>                            ...
>     //this causes dispatch #8  0xb6eb65b4 in impl_sync_and_acquire_instance
> (ctx=0xb6ec98f0 <ilm_context>) at /home/extra/git/wayland-ivi-extension-
> devtool/ivi-layermanagement-
> api/ilmControl/src/ilm_control_wayland_platform.c:1266
>                            <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-
> devtool/ivi-layermanagement-
> api/ilmControl/src/ilm_control_wayland_platform.c:2006
>                            ...
>     //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-
> devtool/ivi-layermanagement-
> api/ilmControl/src/ilm_control_wayland_platform.c:746
>                            ...
>     //first event          #18 0xb65865b4 in dispatch_queue
> (display=display at entry=0x66b80, queue=queue at entry=0x662c8) at
> /home/extra/git/wayland-devtool/src/wayland-client.c:1325
> 
> 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,
> Frederico
> 
> [1]: http://git.projects.genivi.org/?p=wayland-ivi-
> extension.git;a=blob;f=weston-ivi-shell/src/ivi-controller-
> impl.c;h=c16276fcbd5bda35b3519128d725bf6041502acd;hb=HEAD#l1326
> 
> 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 mailing list