| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Detected by clang
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a nameserver is down, we periodically try sending a "probe"
message to that nameserver to see if it has come back up. If a
nameserver comes up, we cancel any pending probe messages.
Cancelling a probe message while handling the probe's response would
result in a access-after-free or a double-free, so when we notice that
we're about to call a nameserver up because of having received a probe
from it, we need to check whether current response is the response
from the probe.
There was a case where we didn't to that, though: when the resolver
gave us an unusual error response to our request that it resolve
google.com. This is pretty rare, but apparently it can happen with
some weird cacheing nameservers -- the one on the mikrotik router, for
example. Without this patch, we would crash with a NULL pointer
derefernce.
Thanks to Hannes Sowa for finding this issue and helping me track it
down.
|
| | |
|
| |
|
|
|
| |
If openssl is not installed system-wide or not compiled as a shared library,
some systems require various link flags (e.g., -ld).
|
| |
|
|
|
|
| |
Windows doesn't have a mode_t as far as I can tell.
Some unixes, iirc, don't like three-argument open without O_CREAT.
|
| |
|
|
|
| |
In a multi-process/threaded environment, opening fds internally
without the close-on-exec flag could leak fds to child processes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We were doing this because of (correct) reports that NetBSD gives an
EBADF when you try to add the write side of a pipe for which the
read side has been closed. But on most kqueue platforms, that
doesn't happen, and on *all* kqueue platforms, reporting a
nonexistent fd (which we usually have if we have seen EBADF) as
readable tends to give programs a case of the vapors.
Nicholas Marriott wrote the original patch here; I did the comment
fixes.
|
| |
|
|
|
|
| |
There was a calloc that needed to be an mm_calloc.
Reported by "fffvvvzz" on sourceforge. Ticket 3486114
|
| | |
|
| |
|
|
|
|
|
|
| |
This is not a perfect fix, but it's much much better than the
current buggy behavior, which could lead to filtering SSL
connections that just stopped reading.
Based on ideas by Maseeb Abdul Qadir and Mark Ellzey.
|
| |
|
|
| |
such as xlc on AIX).
|
| |
|
|
| |
found by Wang Qin
|
| |
|
|
|
| |
On further investigation, it appears that this problem is limited to
AF_UNIX sockets, so let's just do the test on AF_INET sockets.
|
| |
|
|
|
| |
Doing a memcmp risks comparing uninitialized padding bytes at the
end of the structure.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We were supposed to be closing the ev_signal_pair sockets.
|
| |
|
|
|
|
|
|
|
| |
While re-adding all the events, event_reinit() could add a signal
event, which could then cause evsig_add() to add the
base->sig.ev_signal event. Later on its merry path through
base->eventqueue, event_reinit() would find that same event and give
it to event_io_add a second time. This would make the ev_io_next
list for that fd become circular. Ouch!
|
| | |
|
| | |
|
| |
|
|
| |
This sometimes accepted invalid versions like 'ICY' (n = 0, major = undefined, sometimes > 1).
|
| |
|
|
| |
Found by Steve Snyder
|
| |
|
|
|
|
|
|
|
|
|
| |
As originally written, the test would only pass if the accept()
callbacks for the evconnlistener were all invoked before the last of
the CONNECTED/ERROR callbacks for the connecting/resolving bufferevent
had its call to event_base_loopexit() complete. But this was only
accidentally true in 2.0, and might not be true at all in 2.1 where
we schedule event_base_once() callbacks more aggressively.
Found by Sebastian Hahn.
|
| |
|
|
|
|
| |
Older Linuxes sometimes respond to some nmap probes by having accept()
return a success but with socklen 0. That can lead to confusing behavior
when you go to process the sockaddr.
|
| |
|
|
|
|
| |
This should make 64-bit windows act better.
Found by Mark Heily.
|
| |
|
|
| |
Backport by Arno Bakker; original implementation in 8d3a8500f4
|
| | |
|
| |
|
|
|
| |
(Patch altered by nickm to not affect the behavior of
evbuffer_peek(buf,-1,NULL,vec,n_vec).)
|
| |
|
|
| |
Not all C libraries under Linux support the sysctl() func.
|
| |
|
|
|
| |
Apparently, other compilers were allowing "return free(x)" in a
function returning void.
|
| |
|
|
|
|
|
|
| |
I thought we'd fixed the cases where this could come up, but
apparently having an event_base_break() happen while processing
signal events could get us in trouble.
Found by Remi Gacogne. Sourceforge issue 3451433 .
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, if some sender were generating data to read on an
OpenSSL connection as fast as we could process it, we could easily
wind up looping on an openssl do_read operation without ever
considering other sockets.
The difference between this and the original method in
consider_reading() is that it only loops for a single completed
*frame* instead of looping until fd is drained or an error condition
was triggered.
{Patch split out by nickm}
|
| | |
|
| |
|
|
|
|
|
| |
Split up consider_reading()'s conditional checks into another function
can_read() for simplicity sake.
{Split into a separate patch by nickm}
|
| |
|
|
| |
This reverts commit fc52dbac87f4937f8306759506d6a2ad15ca244c.
|
| |
|
|
| |
This reverts commit 7353663eb7c0b2a1caaaa5acd818515f156cf2ca.
|
| | |
|
