Tags: imcotton/swift-nio
Tags
security: ByteBuffer: fix heap buffer overflow on slice realloc Motivation: ByteBuffer had a very bad (exploitable!) security vulnerability if the following conditions are all true: - user writes to a ByteBuffer which is a slice (slice.lowerBound != 0) - the slice is uniquely referenced (ie. the buffer that it was sliced from is gone) - the write triggers a re-allocation Then the slice is actually _larger_ than the overall available capacity so another write to said ByteBuffer could end up out of bounds. Modifications: - fixed slice reallocation Result: - fixed security vulnerability
Widen assertion on readEOF. (apple#453) Motivation: In Darwin it is possible for readEOF to be received before writable, if we race connection teardown with registering for writable. See apple#452 for a more in-depth explanation. Modifications: Widened the assertion. Result: People's code won't go bang.
Don't provide promises when we don't care about results. (apple#437) Motivation: When we don't care about the result of an operation, we shouldn't provide a promise. While I'm here I also removed an unnecessary close() call in the AcceptHandler: the close() would be called again almost immediately. Modifications: Removed a close() call. Set `promise: nil` on a pair of close() calls. Result: Fewer promise allocations.
fix EventLoops that Bootstrap channel initialiser's call out on (appl… …e#424) Motivation: Previously we were not running the (child/server)channelInitializers on the event loop associated to the `Channel` we're initialising. Almost all operations in there are pipeline modifications which are thread safe so it presumably wasn't a massive correctness issue. However it's very expensive to hop threads that often and it is also very unexpected. This addresses this issue. Modifications: made all (child/server)channelInitializers run on the event loop that is associated to their `Channel` Result: - more correctness - less unexpected behaviour
Add ChannelCore.removeHandlers. (apple#408) Motivation: If ChannelPipeline.removeHandlers is internal it is extremely difficult to implement a correct ChannelCore. For that reason, we should make it available as an extension on ChannelCore. This is a minor layering violation, but that's ok: ChannelCore and Channel are not actually intended to be separate objects in most cases, they are just separate for code clarity reasons. Modifications: Add ChannelCore.removeHandlers as a public method. Result: Easier to implement ChannelCore.
fix event loop hop between registration and activation of accepted ch… …annels (apple#389) Motivation: Once again, we had an extra event loop hop between a channel registration and its activation. Usually this shows up as `EPOLLHUP` but not so for accepted channels. What happened instead is that we had a small race window after we accepted a channel. It was in a state where it was not marked active _yet_ and therefore we'd not read out its data in case we received a `.readEOF`. That usually leads to a stale connection. Fortunately it doesn't happen very often that the client connects, immediately sends some data and then shuts the write end of the socket. Modifications: prevent the event loop hop between registration and activation Result: will always read out the read buffer on .readEOF
don't deliver events for unregistered fds (apple#341) Motivation: Since forever we had a major bug in the Selector: In this condition: - kqueue/epoll had many events - in one of the earlier events we unregister a Channel whose fd is on of the later events - we subsequently (still in the same event loop tick) register a new channel which gets the same fd as the previously closed one then we would deliver an event that was meant for a previous channel to a newly opened one. Thanks to @mcdappdev for hitting this bug, helping us debug it and also providing a repeatedly working repro. Modifications: if during event delivery any fd gets unregistered, we stop delivering the remaining events and rely on the selector to redeliver them again next time. Result: we don't deliver events for previously closed channels to new ones.
Ensure correct ordering of promise notification when connect is still… … pending. (apple#330) Motivation: When a pending connect is still in process and the Channel is closed we need to ensure we use the correct ordering when notify the promises and ChannelHandlers in the pipeline. The ordering should be: - Notify pending connect promise - Notify close promise - Call channelInactive(...) Modifications: - Correct ordering of notification - Add unit test Result: Ensure correct ordering when connect is still pending
Don't call to user code before reconciling Channel state. (apple#310) Motivation: Callouts to user code allows the user to make calls that re-enter channel code. In the case of channel closure, we could call out to the user before the channel knew it was completely closed, which would trigger a safety assertion (in debug mode) or hit a fatalError (in release mode). Modifications: Reconciled channel state before we call out to user code. Added a test for this case. Result: Fewer crashes, better channel state management.