Emergency Numbers can only be digits, so there's no point to use the
'Hammer of Thor' that is g_utf8_validate when a much simpler function
will do the job just as well.
XLEMA reports emergency numbers that are hardcoded (e.g. 112 and 911)
and that are already read from EFecc. The additional emergency numbers
we are interested in should only come from the NVM or the network NITZ
update.
This might be either a modem firmware bug or the SIM card is provisioned
really badly, but the last entry contains garbage characters.
ofonod[20620]: Voice: < \r\n+XLEMA: 1,9,"112",,1\r\n\r\n+XLEMA: 2,9,"911",,1\r\n\r\n+XLEMA: 3,9,"000",57,1\r\n\r\n+XLEMA: 4,9,"08",49,1\r\n\r\n+XLEMA: 5,9,"112",49,1\r\n\r\n+XLEMA: 6,9,"118",0,1\r\n\r\n+XLEMA: 7,9,"119",0,1\r\n\r\n+XLEMA: 8,9,"911",0,1\r\n\r\n+XLEMA: 9,9,"999\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377",0,1\r\n
Fix this by just validating the string and cutting off once an invalid
character is found.
==29809== Conditional jump or move depends on uninitialised value(s)
==29809== at 0x4E826C: stk_file_iter_next (stkutil.c:212)
==29809== by 0x4E8CF8: parse_dataobj_file_list (stkutil.c:635)
==29809== by 0x4EBA29: parse_dataobj (stkutil.c:2410)
==29809== by 0x4ECFB5: parse_refresh (stkutil.c:2971)
==29809== by 0x4EECA3: parse_command_body (stkutil.c:3826)
==29809== by 0x4EF0DF: stk_command_new_from_pdu (stkutil.c:3948)
==29809== by 0x4D50DA: ofono_stk_proactive_command_handled_notify
(stk.c:2885)
The default value of sec_level when setting *any* option
using bt_io_set() was BT_SECURITY_MEDIUM. This was causing
the security procedure being started in some situations that
it should not.
Some profiles specify some restriction depending on the length
of the key used to encrypt the link, this adds an way to retrieve
that value from the kernel.