Version-Release number of selected component: menu-cache-0.4.1-3.fc20 Additional info: reporter: libreport-2.1.6 backtrace_rating: 4 cmdline: /usr/libexec/menu-cached crash_function: __gconv_open executable: /usr/libexec/menu-cached kernel: 3.11.0-0.rc6.git4.1.fc21.x86_64 runlevel: N 5 uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #3 __gconv_open at gconv_open.c:282 #4 iconv_open at iconv_open.c:71 #5 try_conversion at gconvert.c:199 #6 g_iconv_open at gconvert.c:251 #7 open_converter at gconvert.c:338 #8 g_convert at gconvert.c:575 #9 g_convert_with_fallback at gconvert.c:671 #10 strdup_convert at gmessages.c:688 #11 g_print at gmessages.c:1466 #12 g_dbus_connection_real_closed at gdbusconnection.c:806 Potential duplicate: bug 958369
Created attachment 789936 [details] File: backtrace
Created attachment 789937 [details] File: cgroup
Created attachment 789938 [details] File: core_backtrace
Created attachment 789939 [details] File: dso_list
Created attachment 789940 [details] File: environ
Created attachment 789941 [details] File: exploitable
Created attachment 789942 [details] File: limits
Created attachment 789943 [details] File: maps
Created attachment 789944 [details] File: open_fds
Created attachment 789945 [details] File: proc_pid_status
Created attachment 789946 [details] File: var_log_messages
*** Bug 958369 has been marked as a duplicate of this bug. ***
You did not provide any reproduction information for this crash, and I've never seen it. Why would it constitute a blocker?
Client crashes are not typically regarded as security flaws if the only issue is a crash. Removing the security bits.
Discussed in 2013-11-06 Blocker Review Meeting [1]. Voted a RejectedBlocker because all [2] these crashes (reported by abrt) don't have reproducers and aren't in crucial components. Please re-propose them later when reproducers are known and we can reconsider blocker status. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-06/ [2] bug 1000669 bug 1000752 bug 1000756 bug 1007121 bug 1015347 bug 1016935
(In reply to Adam Williamson from comment #13) > You did not provide any reproduction information for this crash, and I've > never seen it. Why would it constitute a blocker? It happens on LXDE desktop. Work on it for a while and you get this crash.
(In reply to Vincent Danen from comment #14) > Client crashes are not typically regarded as security flaws if the only > issue is a crash. Removing the security bits. Well I am confused? When exactly is a crash considered as a Security bug? My understanding is that Crash is the same Denial of Service (DoS). And once you do get a crash there is a high possibility to use that crash as a launching pad for executing arbitrary code or for privilege escalation etc etc?
"My understanding is that Crash is the same Denial of Service (DoS)." Um, no, not unless the crashing application is somehow simultaneously accessible by a malicious actor. "And once you do get a crash there is a high possibility to use that crash as a launching pad for executing arbitrary code or for privilege escalation etc etc?" No, not in the case of 'any old crash'. Certain specific types of crash are theoretically avenues of attack in this way, though we have various techniques to mitigate that risk these days.
(In reply to quickbooks.office from comment #17) > (In reply to Vincent Danen from comment #14) > > Client crashes are not typically regarded as security flaws if the only > > issue is a crash. Removing the security bits. > > Well I am confused? When exactly is a crash considered as a Security bug? > > My understanding is that Crash is the same Denial of Service (DoS). And once > you do get a crash there is a high possibility to use that crash as a > launching pad for executing arbitrary code or for privilege escalation etc > etc? Adam explained it quite well, but the bottom line is this: - did _you_ cause the crash? Did you only DoS yourself? Then not security. - did something you downloaded or something somebody else did cause the crash? Does it affect someone else's ability to connect to a service? Then it could very well be. Bottom line is if you do something and you crash your desktop, it's not a security issue. You could just as easily trip over the computer and unplug it and DoS yourself, but that's not a security issue, that's an accident. Now, if you visit my web site and it causes your computer to crash, that would be a different story. And no, a crash does not automatically mean that arbitrary code execution is even remotely on the horizon.
It's not a DoS and no security issue, but it's annoying and fully reproducible. Just open "Applications" in pcmanfm or pcmanfm-qt. There are probably more crash reports related to this. The problem was fixed in 0.5.1 which is in rawhide already. I will therefor request a buildroot overwrite and a freeze exception, however I need to update menu-cache and rebuild libfm and then pcmanfm (not pcmanfm-qt). This is a double buildroot overwrite and requires more testing, but I would appreciate if you support the freeze exception, Adam.
You don't need a freeze exception unless you're planning to land it after Nov 26. We're not frozen until then. http://fedorapeople.org/groups/schedule/f-20/f-20-devel-tasks.html
lxpanel-0.6.1-1.fc20,lxlauncher-0.2.2-4.fc20,pcmanfm-1.1.2-3.D20130830gitfc8adaab77.fc20,libfm-1.1.2.2-3.fc20,menu-cache-0.5.1-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/lxpanel-0.6.1-1.fc20,lxlauncher-0.2.2-4.fc20,pcmanfm-1.1.2-3.D20130830gitfc8adaab77.fc20,libfm-1.1.2.2-3.fc20,menu-cache-0.5.1-1.fc20
Package lxpanel-0.6.1-1.fc20, lxlauncher-0.2.2-4.fc20, pcmanfm-1.1.2-3.D20130830gitfc8adaab77.fc20, libfm-1.1.2.2-3.fc20, menu-cache-0.5.1-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing lxpanel-0.6.1-1.fc20 lxlauncher-0.2.2-4.fc20 pcmanfm-1.1.2-3.D20130830gitfc8adaab77.fc20 libfm-1.1.2.2-3.fc20 menu-cache-0.5.1-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-21536/lxpanel-0.6.1-1.fc20,lxlauncher-0.2.2-4.fc20,pcmanfm-1.1.2-3.D20130830gitfc8adaab77.fc20,libfm-1.1.2.2-3.fc20,menu-cache-0.5.1-1.fc20 then log in and leave karma (feedback).
lxpanel-0.6.1-3.fc20, lxlauncher-0.2.2-4.fc20, pcmanfm-1.1.2-3.D20130830gitfc8adaab77.fc20, libfm-1.1.2.2-3.fc20, menu-cache-0.5.1-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.