A malicious caller can create a SocketAddress for a local unix socket with an
over-long name that does not fit into struct sock_addr_un.
- Socket::connet: This caused the 'sun_path' field to
overflow, probably overwriting the return pointer of the call frame, and thus
crashing the process (in the best case).
- SocketAddress::to_sockaddr_un: This triggered a RELEASE_ASSERT, and thus
crashing the process.
Both have been fixed to return a nice error code instead of crashing.
This is a bit of a pickle and I'm unsure what's the best behavior here.
Since notifiers fire asynchronously via the event loop, we may end up
firing a notifier for a socket fd, but then reading/writing that socket
fd before ending up in the notifier callback.
In that situation, the socket is no longer in the same state as it was
when the event loop generated the notifier event.
This patch stops Socket from firing one hook in this situation but this
probably needs a global rethink.
With this change, Browser starts reliably in multi-process mode. :^)
RefPtr<Notifier> doesn't work quite like it appears to, since the notifier
is also a "child" of the socket, in Core::Object sense. Thus we have to both
remove it from the parent (socket) and drop the additional RefPtr<Notifier> for
it to actually go away.
A proper fix for this would be to untangle parent-child relashionship from
refcounting and inspectability.
This fixes use-after-close of client file descriptors in IPC servers.
The "ready to write" notifier we set up in generic socket connection is
really only meant to detect a successful connection. Once we have a TCP
connection, for example, it will fire on every event loop iteration.
This was causing IRC Client to max out the CPU by getting this no-op
notifier callback over and over.
Since this was only used by TLSv12, I changed that code to create its
own notifier instead. It might be possible to improve TLS performance
by only processing writes when actually needed, but I didn't look very
closely at that for this patch. :^)
