Bug: use-after-free in ivi controller when watched surface is deleted

Frederico Cadete frederico.cadete at awtce.be
Wed Mar 16 10:40:57 EDT 2016


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Avoid-double-destruction-of-surface-context-when-a-c.patch
Type: text/x-diff
Size: 2001 bytes
Desc: not available
URL: <http://lists.genivi.org/pipermail/genivi-ivi-layer-management_lists.genivi.org/attachments/20160316/379978a7/attachment.patch>


More information about the genivi-ivi-layer-management mailing list