8 Jan
2013
8 Jan
'13
8:26 p.m.
Hi all, Daniel,
We've identified a subtle segfault condition in pv module, caused by:
1) tr_eval_string() setting val->rs.s to a constant and read-only ""
(empty string) under certain circumstances in two locations (pv_trans.c
lines 387 and 409),
followed by
2) pv_set_ruri() and others then trying to write to val->rs.s (e.g.
pv_core.c line 1823).
This results in segfault due to modification of read-only memory.
However I'm unsure about the fix: If val->rs.s is allowed to be
read-only, then there should be made no attempts to modify it, or
otherwise if val->rs.s is assumed to be always writable, then the
constant empty string assignment must be removed.
I'll take care of committing the fix once I know which one of the two
choices is the right one.
cheers
8 Jan
8 Jan
8:41 p.m.
Hello,
I would probably replace the constant "" with a pointer to a buffer and
set length to 0 (either a static buffer or one from the pv modue/api
where the values are stored for transformations or evaluation of the
dynamic strings).
That because I expect many places where there is a backup of the next to
last character, then set to 0 for some 0-termnated string operations
(like regexp match) and then restore. That should be safe anywhere, as
non zero terminated values point inside the sip message buffers,
otherwise the std lib string values are null terminated, thus a backup
and restore of 0.
The other solution would require to revise the code and check for
length, even so might not be safe always...
Cheers,
Daniel
On 1/8/13 7:26 PM, Richard Fuchs wrote:
Hi all, Daniel,
We've identified a subtle segfault condition in pv module, caused by:
1) tr_eval_string() setting val->rs.s to a constant and read-only ""
(empty string) under certain circumstances in two locations (pv_trans.c
lines 387 and 409),
followed by
2) pv_set_ruri() and others then trying to write to val->rs.s (e.g.
pv_core.c line 1823).
This results in segfault due to modification of read-only memory.
However I'm unsure about the fix: If val->rs.s is allowed to be
read-only, then there should be made no attempts to modify it, or
otherwise if val->rs.s is assumed to be always writable, then the
constant empty string assignment must be removed.
I'll take care of committing the fix once I know which one of the two
choices is the right one.
cheers
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
4337
days inactive
4337
days old
1 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Richard Fuchs