Bug #3440
closed
USSD related crash of osmo-hlr
Added by laforge over 5 years ago.
Updated over 5 years ago.
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/
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)
- 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.
- Status changed from Feedback to Rejected
I also couldn't reproduce it. I suspect it was an unclean build.
Also available in: Atom
PDF
