looks like sr parser/parse_event.c has the same bug that i found in opensips although the implementations are different.
after statement
end = skip_token(tmp.s, tmp.len);
end points to next char after event string.
then end is assigned to tmp.s
tmp.s = end;
and after that if statement compares this next char to ';':
if (tmp.s[0] == ';') {
which looks wrong to me, because that char can be anything if event does not have any params.
perhaps someone else can recheck if i'm right or wrong.
-- juha
On Sun, Oct 18, 2009 at 12:46 PM, Juha Heinanen jh@tutpro.com wrote:
looks like sr parser/parse_event.c has the same bug that i found in opensips although the implementations are different.
after statement
end = skip_token(tmp.s, tmp.len);
end points to next char after event string.
then end is assigned to tmp.s
tmp.s = end;
and after that if statement compares this next char to ';':
if (tmp.s[0] == ';') {
which looks wrong to me, because that char can be anything if event does not have any params.
perhaps someone else can recheck if i'm right or wrong.
Yes, I think this is a bug. The bug won't be triggered if event_parser is only called from parse_event, but given that some modules use event_parser directly, it can happen that it will try to read a character which does not belong to the string given in arguments anymore.
I will fix it, thanks.
-- Jan
Jan Janak writes:
Yes, I think this is a bug. The bug won't be triggered if event_parser is only called from parse_event, but given that some modules use event_parser directly, it can happen that it will try to read a character which does not belong to the string given in arguments anymore.
i have seen it happening a couple of times, i.e., event didn't have params, but the next char in memory just happened to be ';'.
-- juha
-
Jan Janak -
jh＠tutpro.com -
Juha Heinanen