Summary: | CVE-2024-36041 patches in 6.0.5.1 break shutdown/restart on X11 | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | Kevin Kofler <kevin.kofler> |
Component: | Session Management | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | REOPENED --- | ||
Severity: | normal | CC: | anton.schenker, herloncamargo, jmc-kde, kde, lassi.vaatamoinen, natalie_clarius, nate, orontobate, postix, qydwhotmail, sergio, waynenail |
Priority: | NOR | Keywords: | regression |
Version: | 6.0.5 | ||
Target Milestone: | 1.0 | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
URL: | https://bugzilla.redhat.com/show_bug.cgi?id=2290894 | ||
See Also: |
https://bugzilla.redhat.com/show_bug.cgi?id=2290894 https://bugs.kde.org/show_bug.cgi?id=490344 |
||
Latest Commit: | Version Fixed In: | 6.1.0 | |
Sentry Crash Report: |
Description
Kevin Kofler
2024-06-07 23:36:33 UTC
I just experienced this on Wayland with current git master too, Maybe it's not limited to X11 if it's the same issue. Cannot reproduce with X11, master There was a follow-up commit that added an fclose, without that it's racey as to whether the iceauthority is synced or not. It got lost in the final reshuffles, and somehow worked when testing. 0857d18dfc3fc870a7f768731fdf46dc3abc5f8f It is fixed in 6.1 and master Maybe we should make a 6.0.5.2 The plasma-workspace-6.0.5.1-2.fc40 build that the reporter is using already has this patch applied: https://src.fedoraproject.org/rpms/plasma-workspace/c/227a33c9b49cb70649c05ac16476f349667d6e36?branch=f40 It does not fix the issue. Maybe we should revert the "Remove iceauth dependency" parts, keep only the actual security fix, and just add a Requires: iceauth to the package? (Though I have not verified whether that fixes it or whether the security fix alone is already enough to trigger the bug.) We should do some research before doing any actions. Is ICEAUTHORITY set? What are the contents of where it points? What's the stderr when we start dolphin on X11? Quoting the downstream report: --- Comment [https://bugzilla.redhat.com/show_bug.cgi?id=2290894#c15] from EpicTux123 --- Hi there Kevin. Thanks for making it easier for me. Here you go: https://0.jaegers.net/?23a726b30013e7aa#5ZX2ivqqZCnpwnAu13bSxz4aeaqXMRDsw6hjZnCkowCo "dolphin" didn't output anything except if I walked through some folders. That's why there is some spam in the output. The file "/run/user/1000/iceauth_MfWxAr" points to the tmp folder as you can see in the output. "MIT-MAGIC-COOKIE 1" appears inside it many times. Weird, if auth fails I would expect: 8:01:47.431 ?libQt6XcbQpa.so.6?|QXcbIntegration::createPlatformSessionManager|QSessionManagerPrivate::QSessionManagerPrivate Qt: Session management error: None of the authentication protocols specified are supported Which implies nothing of the parts we changed is broken. At what message level is that printed? It might be that the message is not shown by default on Fedora because the default settings are quite restrictive to limit terminal spam from KDE applications. At least we used to do that. I have not been involved with those settings for a while, so I would have to double-check. (To be honest, I have always complained that we still print way too many debugging messages to the terminal and would have restricted the logging even further if it had been my decision to make, silencing anything except qFatal.) These are the settings we ship: https://src.fedoraproject.org/rpms/qt6-qtbase/blob/rawhide/f/qtlogging.ini [Rules] *.debug=false qt.qpa.xcb.xcberror.warning=false But the message appears to be an uncategorized qWarning: https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/xcb/qxcbsessionmanager.cpp?h=6.7.2#n343 so it should be shown by default. Never mind from me; the issue I was experiencing was something else, and not the exact issue being reported here. Whilst I'm sure the reporter does have a bug, it doesn't seem to be a global issue. Lowering severity. We already have a duplicate report downstream: https://bugzilla.redhat.com/show_bug.cgi?id=2291334 We now have at least 3 users who can reproduce this downstream. This is not a configuration issue on an individual machine. JFYI I can't reproduce the issue in my built-from-source X11 session, built on top of Fedora 40. Is it possible this is a downstream packaging issue? I'm also having this exact same problem. To shutdown, reboot or logout I need to use TTY or CLI in Konsole. This only happens in the X11 session. At Wayland everything is normal. One report today said things started out working then started failing. (with the error message that I was expecting). Not sure what could cause that but it would make the debug make sense. *** Bug 488614 has been marked as a duplicate of this bug. *** I updated all my packages today, this took Plasma from 6.0.5 to 6.1.0 and I am now able to shutdown from KDE without any problem. We have a user downstream who is still running into this bug with the latest Fedora 40 updates, which should mean plasma-workspace 6.1.1: https://bugzilla.redhat.com/show_bug.cgi?id=2290894#c22 Plasma 6.1.1, plasma-workspace-x11-6.1.1-1.fc40.x86_64, kernel 6.9.7-200.fc40.x86_64, AMD Phenom II X4 955, AMD RX570. Neither the Log Out, Reboot, or Power buttons on Application Menu have any effect at all. I use 'systemctl reboot' in a root terminal tab. Mark T. Kennedy wrote downstream [https://bugzilla.redhat.com/show_bug.cgi?id=2290894#c27]: > this bug is still in Fedora 40 (completely up-to-date as of 7/19/24). specifically kernel v6.9.9 and plasma-workspace-x11 v6.1.2-1. exists on bare metal as well as vmware VM's. > > one thing i've noticed (not sure if it is relevant) is that on some instances of this problem, after i choose reboot or shutdown from the kde app launcher, it will kill most things and display a dark screen *except* for some remote gkrellm processes i run via ssh and X11 forwarding. they continue to run until a command line shutdown, reboot, or sddm restart. more one bug related *** Bug 490344 has been marked as a duplicate of this bug. *** I had the same bug on Gentoo: I was restoring a previous saved session on login. I tried to start with empty session and delete .config/session/ content and now it works. The problem is probably related to the session manager somehow... Sorry for the double post: if I enable again the session restore the bug reappears. Operating System: Gentoo Linux 2.15 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.6.47-DvD (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 31,2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 530 |