#863 Slash in menu name isn't supported (was: menu-cache-gen segfaulting with libfm-extra 1.2.5)

[Raphael Hertzog]

In Kali we are providing /etc/xdg/menus/applications-merged/kali-applications.menu to customize the menu structure. We are adding many top-level categories and are moving the existing ones one level deeper (below "Usual applications"). This used to work fine until a few week ago when we switched from libfm-extra4 1.2.4 to 1.2.5. This has been reported to Kali here: https://bugs.kali.org/view.php?id=3822

It looks like that menu-cache-gen is now segfaulting and the user is left without any menu. I tried to come up with a backtrace but it's not entirely clear how that binary is actually called...

Here's my try to reproduce the issue:

$ gdb /usr/lib/menu-cache/menu-cache-gen
[...]
(gdb) run -i /etc/xdg/menus/applications-merged/kali-applications.menu -o /tmp/output
Starting program: /usr/lib/menu-cache/menu-cache-gen -i /etc/xdg/menus/applications-merged/kali-applications.menu -o /tmp/output
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
fm_xml_file_item_get_data (item=0x0, text_size=text_size@entry=0x0) at extra/fm-xml-file.c:1453
(gdb) bt
#0  fm_xml_file_item_get_data (item=0x0, text_size=text_size@entry=0x0) at extra/fm-xml-file.c:1453
#1  0x00005555555588f3 in _make_menu_node (node=<optimized out>, def=def@entry=0x7fffffffe410)
    at menu-merge.c:1616
#2  0x00005555555589d3 in _make_menu_node (node=<optimized out>, def=def@entry=0x7fffffffe410)
    at menu-merge.c:1599
#3  0x00005555555589d3 in _make_menu_node (node=node@entry=0x5555557844a0, def=def@entry=0x7fffffffe410)
    at menu-merge.c:1599
#4  0x000055555555b1ae in get_merged_menu (file=<optimized out>, xmlfile=0x7fffffffe488, 
    error=0x7fffffffe490) at menu-merge.c:1816
#5  0x000055555555752d in main (argc=<optimized out>, argv=<optimized out>) at main.c:140

[Raphael Hertzog]

To be clear, I have the feeling that the above backtrace does not match the segfault experienced by users because I have probably called menu-cache-gen in some unexpected way. If you can tell me how it's really called I can provide you a more useful backtrace.

Right now I see a crash on this line:

   1616                 menu->name = g_strdup(fm_xml_file_item_get_data(fm_xml_file_item_find_child(l->data,
   1617                                                         FM_XML_FILE_TEXT), NULL));

And l->data points to a "\r" string and l->next->data points to "\020" and l->next->next->data points to "\002" (and that's the end of the linked list). I'm not sure what this means but I wanted to share it.

[Mamoru TASAKA]

Reduced testcase.

Reproducible with

/usr/libexec/menu-cache/menu-cache-gen -i $(pwd)/tmp1.menu -o tmptmp

with menu-cache 1.0.2, libfm-extra-1.2.5. Note that with --verbose mode, menu-cache-gen "fails":

$ /usr/libexec/menu-cache/menu-cache-gen --verbose -i $(pwd)/tmp1.menu -o tmptmp
menu-cache-gen: XML file '/home/mtasaka/rpmbuild/fedora-specific/TMP/tmp1.menu' error (6:42): Invalid <Name> tag

[Mamoru TASAKA]

So gdb shows that when process reaches _menu_xml_handler_Name() for <Name>Network / Port Scanners</Name> entry, name variable actually points to "Network / Port Scanners", which contains '/', then

• with --verbose option, _menu_xml_handler_Name() returns 0
• On the other hand, without --verbose option, _menu_xml_handler_Name() returns 1, because of RETURN_TRUE_AND_DESTROY_IF_QUIET(item);. So without --verbose option, fm_xml_file_item_destroy(item) is executed and return 1.

Then later, as item is already destroyed, the segv above happens at fm_xml_file_item_get_data().

So I guess "return 0" in RETURN_TRUE_AND_DESTROY_IF_QUIET macro is wrong. Perhaps just nuking this macro is the simplest fix.

[Mamoru TASAKA]

So I guess "return 0" in RETURN_TRUE_AND_DESTROY_IF_QUIET macro is wrong.

Oops, this should be : So I guess "return TRUE" in RETURN_TRUE_AND_DESTROY_IF_QUIET macro is wrong.

[Lonely Stranger]

Thank you very much for investigations! At last the source point is caught. Although simply allowing '/' to be in name will cause problems since that name will be used in menu path later, so it require additional work in libmenu-cache (menu-cached isn't affected). Will check that when time permits ASAP.

[Mamoru TASAKA]

Just a workaround for preventing segfaults.

[Lonely Stranger]

Thank you very much for a workaround. Although actual problem lies in _menu_xml_handler_Name() where item was incorrectly reused, and still the slash in name should be handled somehow, as simply ignore the menu might be not exactly what the user wants. The hotfix for crash is pushed into git, I didn't tested it well but I hope it will not crash anymore.

[Mamoru TASAKA]

I tested menu-cache git head and actually this segv is no longer reproducible, thank you.

[Lonely Stranger]

Thank you for a confirmation. Since crash is fixed but menu folders with a slash still are not supported, I leave this issue open but lower priority on it. May be to open another bug report would be a better way, though, but more complicated. :)