Bug 408358

Summary: Use after free in KDE Wayland integration
Product: [Frameworks and Libraries] kwayland Reporter: Michael Weghorn <m.weghorn>
Component: clientAssignee: Martin Flöser <mgraesslin>
Status: RESOLVED WORKSFORME    
Severity: normal CC: glogow, kde, m.weghorn, nate
Priority: NOR    
Version: 5.58.0   
Target Milestone: ---   
Platform: Neon   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Valgrind output with wayland built from git master on KDE Neon unstable

Description Michael Weghorn 2019-06-05 20:21:39 UTC
Created attachment 120608 [details]
Valgrind output with wayland built from git master on KDE Neon unstable

SUMMARY

There is a use-after free problem in plasma-integration/libkf5waylandclient/libwaylandclient.

STEPS TO REPRODUCE
1. log into a Plasma Wayland session
2. start any KDE (or Qt widget) application with environment variables 'MALLOC_CHECK_=2 MALLOC_PERTURB' set.


OBSERVED RESULT

The application crashes, e.g. like this:

    $ MALLOC_CHECK_=2 MALLOC_PERTURB_=153 kate
    kate: ../src/wayland-client.c:226: wl_proxy_unref: Assertion `proxy->refcount > 0' failed.
    Aborted (core dumped)

EXPECTED RESULT

The application should run just fine.


SOFTWARE/OS VERSIONS

VM with:

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.16.80
KDE Frameworks Version: 5.59.0
Qt Version: 5.12.0
Kernel Version: 4.18.0-21-generic
OS Type: 64-bit
Processors: 4 × Intel Xeon E3-12xx v2 (Ivy Bridge)
Memory: 7,7 GiB of RAM

ADDITIONAL INFORMATION

* Package versions on KDE Neon (originally observed in Debian testing with older versions):
  * plasma-integration: 5.15.5+p18.04+git20190604.0336-0
  * libkf5waylandclient5: 4:5.58.0+p18.04+git20190602.0143-0
* The real world use case is LibreOffice with its relatively new qt5/kde5 integration. The LibreOffice shell wrapper sets the above two environment variables, so LibreOffice currently doesn't start in a Plasma Wayland session with kde5 integration in use.
* The same happens when using upstream wayland libs built from its current master branch (as of commit 78c8681e28739da1fea667ae59118cfc0968497).
* Valgrind output for that scenario attached.
Comment 1 David Edmundson 2019-06-22 16:30:10 UTC
[18:21] <d_ed> you don't want to create a second XdgShellSurface, Qt has one internally
[18:25] <d_ed> it's a protocol violation so a correct compositor should kick out the client
[18:26] <d_ed> unfortunately Qt's XdgShellTopLevel object is not exposed anywhere


That needs a patch in Qt at which point we may as well support setAppId explicitly there.

Will leave this open to remind us to fix.
Comment 2 Michael Weghorn 2020-12-11 12:02:17 UTC
I can't reproduce this anymore with Plasma 5.19.5 on a current Debian testing (with libwayland-client0 1.18.0-2~exp1.1, plasma-integration 5.19.5-3).

-> Closing as WORKSFORME

(In reply to David Edmundson from comment #1)
> [18:21] <d_ed> you don't want to create a second XdgShellSurface, Qt has one
> internally
> [18:25] <d_ed> it's a protocol violation so a correct compositor should kick
> out the client
> [18:26] <d_ed> unfortunately Qt's XdgShellTopLevel object is not exposed
> anywhere
> 
> 
> That needs a patch in Qt at which point we may as well support setAppId
> explicitly there.
> 
> Will leave this open to remind us to fix.

@David: I don't immediately see how this is related to the issue originally reported here - to me, this comment sounds more related to https://bugreports.qt.io/browse/QTBUG-77182 (Qt: "Export Wayland xdg_toplevel app ID to allow changing the icon of a Window") and  https://bugs.documentfoundation.org/show_bug.cgi?id=125934 (LibreOffice: "No application icon on Wayland with the qt5 / kf5 backend") , respectively...