Stefan Knoblich [Tue, 21 May 2013 15:42:24 +0000 (17:42 +0200)]
ftmod_libpri: Fix possible NULL-ptr dereference crash in on_restart(_ack)()
Catch single channel RESTART/RESTART ACK events for non-B-channels,
that would lead to a NULL pointer dereference, because those do not have
per-channel private data (chan->call_data = chan_priv == NULL).
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
William King [Sun, 19 May 2013 02:13:18 +0000 (19:13 -0700)]
full_contact must be freed by sofia. There isn't a chance of this having blown anything up, but Coverity is right that this should be initialized with NULL to be safe against future refactors.
William King [Sun, 19 May 2013 00:34:16 +0000 (17:34 -0700)]
Coverity reported an Uninitialized pointer read. Upon further digging it appears that there is a code path where incoming packets can come in out of order, so this section of code tries to see if it can find the missed packets. As per FS-5202 there is a case where under heavy load the packet exists, and has most of the packet parsed, but still has a NULL pointer for the packet buffer. These two lines would at least help detect the edge case.
William King [Sun, 19 May 2013 00:00:41 +0000 (17:00 -0700)]
Possible leak if someone were to try and add extra headers to a channel that had either an inbound info on that session or the session were to be deflected. I don't see a way that these extra headers could be added outside of a C module subscribing to the session states, but just to make sure I'm adding these so that just like other extra header locations it's cleaned up.
William King [Sat, 18 May 2013 23:34:46 +0000 (16:34 -0700)]
Alice meet rabit hole. There is a leak here on every invite that comes back from a status 180 when the other side is not FS, but you have presence enabled. Thanks to Coverity scan for location this condition. This 'might' not have been leaking if sofia was automatically freeing this when the sofia object was destroyed, but all other locations where sip_header_as_string where called they were all followed by a su_free, so I assume not.
William King [Sat, 18 May 2013 22:10:44 +0000 (15:10 -0700)]
When message events were added, the debug field name was overlooked. This would have only been hit when debug level was above 'DEBUG1' and at that point it would have incorrectly chosen debug display names.
William King [Sat, 18 May 2013 20:38:24 +0000 (13:38 -0700)]
This was writing a null one space to the right, outside of the malloc'd buffer. On further review this uses apr_vsnprintf which always returns null terminated.
William King [Mon, 13 May 2013 22:10:03 +0000 (15:10 -0700)]
Since there isn't neutral ground, on the rtmp state callback we actually have to force the write lock of the session, but we only need a try lock on removing the session from the rsession->session_hash. This removes a deadlock caused when we had to enforce with locks that the rsession couldn't be destroyed if the FS session was in the middle of a hangup.
Steve Underwood [Fri, 10 May 2013 03:54:20 +0000 (11:54 +0800)]
The gettimeofday() function spandsp provided for Windows apparently falls over
after 25 hours. I guess not many people are inserting header lines on FAX pages.
Hopefully this update fixes the problem.
FS-5325 i'll put the nonblocking in but I still think this is a problem with openssl, a short read is not there every single time you connect, When the lib is in full blocking mode it should be handling the complicated actions internally. As complicated as socket programming is, async ssl is even worse because it requires you to do your own buffering and attemps to read may fail waiting for you to write or vice-versa which should have been handled for us in the lib. non-interruptable syscalls are getting pretty outdated and not enabling it is much less complex than making every socket app on earth be non-blocking
William King [Thu, 9 May 2013 01:45:24 +0000 (18:45 -0700)]
FS-5395: False alarm on a reported valgrind memory leak. The io_private is alloc'd from a memory pool which valgrind sucks at tracking. No need to free this, because it'll get cleared when the memory pool on the rsession is destroyed.