[bug]: possible use-after-free (revealed as invalid utf-8 in appname and appdata in CEL)

[sshilovsky]

Severity

Minor

Versions

20.5.1

Components/Modules

pjsip,cel_odbc

Operating Environment

Ubuntu 22.04.4 LTS

Frequency of Occurrence

Constant

Issue Description

In the following scenario asterisk attempts to write invalid utf-8 characters into CEL table.

Reproduce

consider this dialplan:

[out-000]
exten => 800,1,Wait(60)
exten => 801,1,Noop()
	same => n,Dial(PJSIP/801,120,tT)
	same => n,HangUp()
switch =>Realtime/out-000@realtime_ext
exten => 802,1,Noop() ; exten 802 has to be in realtime db. only shown here as example
	same => n,Dial(PJSIP/802,60,tThH)
	same => n,HangUp()

• dial 800 (from 411 in my setup)
• channel redirect PJSIP/411-xxxxxxxx out-000,801,1 - redirect the original caller 411 to 801
• channel redirect PJSIP/801-xxxxxxxx out-000,802,1 - connect 801 and 802 (disconnecting the original caller 411)
• hang up either 801 or 802

If dialplan for 802 is specified in config file, everything is fine at this point and the call is finalized correctly.
If, and only if, the dialplan for 802@out-000 is specified in realtime (postgres in my case), asterisk fails to record a few event into cel table (see log output).

Relevant log output

[2024-05-13 13:26:07.547] WARNING[187282] res_odbc.c: SQL Execute returned an error: 22021: ОШИБКА: неверная последовательность байт для кодировки "UTF8": 0x94;
Error while preparing parameters
[2024-05-13 13:26:07.548] WARNING[187282] res_odbc.c: SQL Execute error -1!
[2024-05-13 13:26:07.549] WARNING[187282] cel_odbc.c: Insert failed on 'asterisk:cel'.  CEL failed: INSERT INTO cel (eventtype, eventtime, userdeftype, cid_name, cid_num, cid_ani, cid_rdnis, cid_dnid, exten, context, channame, appname, appdata, amaflags, accountcode, peeraccount, uniqueid, linkedid, userfield, peer) VALUES ('HANGUP', {ts '2024-05-13 10:26:07.511336'}, '', '', '801', '', '', '', 'h', 'out-000', 'PJSIP/0911-00000110', '�', 'P�����', 3, '', '', '1715595946.2275', '1715595940.2273', '', '')
[2024-05-13 13:26:07.551] WARNING[187282] res_odbc.c: SQL Execute returned an error: 22021: ОШИБКА: неверная последовательность байт для кодировки "UTF8": 0x94;
Error while preparing parameters
[2024-05-13 13:26:07.552] WARNING[187282] res_odbc.c: SQL Execute error -1!
[2024-05-13 13:26:07.553] WARNING[187282] cel_odbc.c: Insert failed on 'asterisk:cel'.  CEL failed: INSERT INTO cel (eventtype, eventtime, userdeftype, cid_name, cid_num, cid_ani, cid_rdnis, cid_dnid, exten, context, channame, appname, appdata, amaflags, accountcode, peeraccount, uniqueid, linkedid, userfield, peer) VALUES ('CHAN_END', {ts '2024-05-13 10:26:07.511336'}, '', '', '801', '', '', '', 'h', 'out-000', 'PJSIP/0911-00000110', '�', 'P�����', 3, '', '', '1715595946.2275', '1715595940.2273', '', '')
[2024-05-13 13:26:07.554] WARNING[187282] res_odbc.c: SQL Execute returned an error: 22021: ОШИБКА: неверная последовательность байт для кодировки "UTF8": 0x94;
Error while preparing parameters
[2024-05-13 13:26:07.555] WARNING[187282] res_odbc.c: SQL Execute error -1!
[2024-05-13 13:26:07.555] WARNING[187282] cel_odbc.c: Insert failed on 'asterisk:cel'.  CEL failed: INSERT INTO cel (eventtype, eventtime, userdeftype, cid_name, cid_num, cid_ani, cid_rdnis, cid_dnid, exten, context, channame, appname, appdata, amaflags, accountcode, peeraccount, uniqueid, linkedid, userfield, peer) VALUES ('LINKEDID_END', {ts '2024-05-13 10:26:07.511336'}, '', '', '801', '', '', '', 'h', 'out-000', 'PJSIP/0911-00000110', '�', 'P�����', 3, '', '', '1715595946.2275', '1715595940.2273', '', '')

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

[mbradeen]

Hi @sshilovsky - is it possible to get the schema and a table dump for your setup?

[sshilovsky]

@mbradeen

CREATE TABLE public.extensions (
    id bigint NOT NULL,
    context character varying(40) NOT NULL,
    exten character varying(40) NOT NULL,
    priority integer NOT NULL,
    app character varying(40) NOT NULL,
    appdata character varying(256) NOT NULL
);

CREATE TABLE public.cel (
    id bigint NOT NULL,
    eventtype character varying(30) NOT NULL,
    eventtime timestamp without time zone DEFAULT timezone('utc'::text, now()) NOT NULL,
    userdeftype character varying(255) NOT NULL,
    cid_name character varying(80) NOT NULL,
    cid_num character varying(80) NOT NULL,
    cid_ani character varying(80) NOT NULL,
    cid_rdnis character varying(80) NOT NULL,
    cid_dnid character varying(80) NOT NULL,
    exten character varying(80) NOT NULL,
    context character varying(80) NOT NULL,
    channame character varying(80) NOT NULL,
    appname character varying(80) NOT NULL,
    appdata text NOT NULL,
    amaflags integer NOT NULL,
    accountcode character varying(20) NOT NULL,
    peeraccount character varying(20) NOT NULL,
    uniqueid character varying(150) NOT NULL,
    linkedid character varying(150) NOT NULL,
    userfield character varying(255) NOT NULL,
    peer character varying(80) NOT NULL,
    consumed public.t_consumed DEFAULT 'NEW'::public.t_consumed NOT NULL,
    test_consumed_stage public.t_consumed DEFAULT 'NEW'::public.t_consumed NOT NULL,
    test_consumed_s public.t_consumed DEFAULT 'NEW'::public.t_consumed NOT NULL,
    tsnow timestamp without time zone DEFAULT timezone('utc'::text, now())
);

which tables / data do you want me to dump?

PS reproduced on 20.7.0

[jcolp]

Essentially what we're asking for is the required schema and dump to completely reproduce this issue ourselves, so that we don't have to assume things.

[asteriskteam]

This issue has been marked stale because it has been open 7 days with no feedback. Please provide feedback within 7 days or this issue will be closed.

[sshilovsky]

freshly reproduced with this dump:

dump72.zip

[jcolp]

And how did you come to the conclusion of a "possible use-after-free"?

[sshilovsky]

And how did you come to the conclusion of a "possible use-after-free"?

In short, it's a guess, based on:

1. the invalid data seem to be some random value, but the same for the 3 events of the same call (HANGUP, CHAN_END, LINKEDID_END)
2. we could only reproduce it when the original caller is dismissed early from the call.

We could absolutely be wrong, hence "possible"