Bug #3440
closedUSSD related crash of osmo-hlr
0%
Description
Yesterday, roh discovered an USSD related crash of osmo-hlr. The crash happened several seconds after the MS first issued the USSD request for #100, and in a situation where the response message routing somehow didn't work as expected (possibly due to IPA CCM ID RESP parsing bugs with extaneous 0x00, see https://gerrit.osmocom.org/#/c/libosmocore/+/10216/
Updated by roh almost 6 years ago
i retestet it with todays nightly build and installed gdb:
20180801193601803 DLINP <0007> input/ipa.c:385 connected read/write 20180801193601803 DLINP <0007> input/ipa.c:340 127.0.0.1:35378 message received 20180801193611785 DLINP <0007> input/ipa.c:385 connected read/write 20180801193611785 DLINP <0007> input/ipa.c:340 127.0.0.1:35376 message received 20180801193611786 DSS <0004> hlr_ussd.c:465 901700000023840/0x20000002: Process SS (BEGIN) 20180801193611786 DSS <0004> hlr_ussd.c:130 Found EUSE ATUL�NSL��\ (prefix *#100#) for USSD Code '*#100#' 20180801193611786 DSS <0004> hlr_ussd.c:414 901700000023840/0x20000002: USSD CompType=Invoke, OpCode=ProcessUssReq '*#100#' '0180801193611786 DSS <0004> hlr_ussd.c:274 901700000023840/0x20000002: Tx USSD 'Your extension is 23840 20180801193611786 DLGSUP <000f> gsup_send.c:38 Cannot find route for addr MSC-00-00-00-00-00-00 20180801193616063 DLINP <0007> input/ipa.c:385 connected read/write 20180801193616063 DLINP <0007> input/ipa.c:340 127.0.0.1:35376 message received 20180801193621802 DLINP <0007> input/ipa.c:385 connected read/write 20180801193621802 DLINP <0007> input/ipa.c:340 127.0.0.1:35378 message received 20180801193636064 DLINP <0007> input/ipa.c:385 connected read/write 20180801193636064 DLINP <0007> input/ipa.c:340 127.0.0.1:35376 message received 20180801193639561 DLINP <0007> input/ipa.c:385 connected read/write 20180801193639561 DLINP <0007> input/ipa.c:340 127.0.0.1:35376 message received 20180801193639561 DSS <0004> hlr_ussd.c:465 901700000023840/0x20000002: Process SS (END) Program received signal SIGSEGV, Segmentation fault. handle_ss (ss=ss@entry=0x555555831620, req=<optimized out>, gsup=<optimized out>) at hlr_ussd.c:396 396 hlr_ussd.c: No such file or directory. (gdb) bt #0 handle_ss (ss=ss@entry=0x555555831620, req=<optimized out>, gsup=<optimized out>) at hlr_ussd.c:396 #1 0x0000555555561882 in rx_proc_ss_req (conn=0x55555582e2a0, gsup=0x55555576bc80 <gsup>) at hlr_ussd.c:544 #2 0x000055555555e76f in read_cb (conn=0x55555582e2a0, msg=0x555555830f60) at hlr.c:408 #3 0x000055555555d5cb in osmo_gsup_server_read_cb (conn=0x55555582f330, msg=0x555555830f60) at gsup_server.c:106 #4 0x00007ffff710bc9e in ?? () from /usr/lib/x86_64-linux-gnu/libosmoabis.so.6 #5 0x00007ffff7325022 in osmo_select_main () from /usr/lib/x86_64-linux-gnu/libosmocore.so.11 #6 0x0000555555557d69 in main (argc=5, argv=0x7fffffffec08) at hlr.c:637 (gdb)
Updated by fixeria almost 6 years ago
- Status changed from New to Feedback
I am trying to reproduce this segfault (with ASAN compiled in), but with the recent
source code everything works like a charm :) I also experienced some segfaults before,
but I think they were related to to IPA CCM ID RESP parsing, as Harald pointed out...
The only problem I have discovered is that the default route is ignored, and doesn't
affect the USSD processing. But, this is a topic for another issue.
Updated by laforge over 5 years ago
- Status changed from Feedback to Rejected
I also couldn't reproduce it. I suspect it was an unclean build.