This commit stops using deprecated WSA functions. While the ANSI
versions are most likely not going anywhere, Windows is natively UTF-16
so it has to convert to ANSI internally. All the ANSI functions in
Winsock are marked as deprecated. The macro suppressing the warnings is
no longer defined.
Previously, IPC messages were decoded on the main thread:
1. I/O thread received raw bytes and file descriptors
2. I/O thread stored them in a queue and notified main thread
3. Main thread decoded bytes into Message objects
4. Main thread processed the messages
Now, decoding happens on the I/O thread:
1. I/O thread receives raw bytes and file descriptors
2. I/O thread decodes them using a configurable MessageDecoder
3. I/O thread calls MessageHandler which stores decoded messages
4. I/O thread signals condition variable (for sync waiters)
5. I/O thread wakes main event loop via deferred_invoke()
6. Main thread processes already-decoded messages
This is achieved by:
- Adding MessageDecoder and MessageHandler callbacks to TransportSocket
- Connection template sets up the decoder (tries both endpoints)
- ConnectionBase::initialize_messaging() sets up the handler
- Storing a WeakEventLoopReference to wake the main thread
- Using mutex + condition variable for thread-safe queue access
- Sync message waiting now uses the CV directly instead of polling
The raw message API (read_as_many_messages_as_possible_without_blocking)
is preserved for MessagePort which uses its own decoding logic.
This architecture prepares for future multi-thread dispatch where
different message types could be routed to different handler threads
(e.g., scrolling messages to a dedicated scroll thread).
Previously, when an IPC message failed to parse, we only logged
"Failed to parse IPC message" followed by a hex dump, making it
difficult to diagnose the actual cause.
Now we log the specific error from each endpoint's decode attempt,
making it much easier to identify issues like size limit violations
or invalid field values.
AnonymousBuffer is backed by shared memory, not heap allocation.
The MAX_DECODED_SIZE limit in decode_size() is meant to prevent OOM
from malicious peers claiming huge sizes that would cause heap
allocations, but this doesn't apply to AnonymousBuffer since the
memory is already allocated by the sender.
This fixes decoding of large animated images (e.g. 300 frames at
240x240) where the total bitmap data exceeds 64 MiB.
Also add upfront bounds checking for variant indices before entering
the recursive template, allowing us to convert the template's fallback
error into VERIFY_NOT_REACHED() since the index is now guaranteed to
be valid when we enter the recursive decode.
- VERIFY that IPC::File has a valid fd (>= 0) before encoding
- VERIFY that container sizes fit in u32 before encoding
These catch programming errors where we accidentally try to encode
invalid data. Encoding bugs should crash immediately so we catch them
during development.
Add VERIFY assertions to catch bugs where we accidentally try to send
messages that exceed MAX_MESSAGE_PAYLOAD_SIZE or MAX_MESSAGE_FD_COUNT.
These are programming errors and should crash immediately so we catch
them during development, rather than silently sending invalid data.
This consolidates the message size and FD count limits into a single
header file that can be used by both the encoding and decoding sides
of the IPC layer.
A malicious peer could claim that a string, buffer, or vector has an
extremely large size (up to 4 GiB), causing allocation failures or OOM.
Add MAX_DECODED_SIZE (64 MiB) check in decode_size() to reject
excessively large containers before attempting allocation.
A malicious or misbehaving peer could send data faster than we process
it, causing unbounded memory growth in the unprocessed bytes buffer
and file descriptor queue.
Add MAX_UNPROCESSED_BUFFER_SIZE (128 MiB) and MAX_UNPROCESSED_FDS (512)
limits. When exceeded, the peer is disconnected gracefully rather than
allowing memory exhaustion.
Reject messages from peers that exceed reasonable limits:
- Maximum payload size: 64 MiB
- Maximum file descriptor count: 128
Also use checked arithmetic for message size calculations to prevent
integer overflow attacks.
These limits prevent malicious peers from causing excessive memory
allocation or resource exhaustion.
post_message() returns ErrorOr but was using MUST internally for
transfer_message(). If the transfer fails (e.g., socket error), we
would crash instead of propagating the error to the caller.
The message parsing loop performs arithmetic on payload_size (u32) and
index (size_t). While overflow is unlikely on 64-bit systems, use
Checked<size_t> to explicitly validate:
1. message_size = payload_size + sizeof(MessageHeader)
2. new_index = index + payload_size + sizeof(MessageHeader)
This prevents potential integer overflow attacks from malicious peers.
Replace crash-on-OOM patterns with graceful error handling:
- Use try_append() instead of append() for buffer operations
- Handle ByteBuffer::copy() failure instead of using MUST()
A malicious peer could send messages with large payload sizes to
trigger OOM conditions. Instead of crashing, we now disconnect
the misbehaving peer.
The previous code used Vector::resize() which internally uses MUST(),
causing a crash if memory allocation fails. A malicious peer could
send a message with a large vector size to trigger OOM and crash the
recipient.
Use try_resize() instead to propagate the error gracefully.
A malicious peer could exploit the file descriptor acknowledgement
protocol in several ways:
1. Send messages with fd_count values that overflow when accumulated
2. Send acknowledgements claiming more FDs were received than we sent
Both attacks would crash the recipient via VERIFY failures in
Queue::dequeue() or integer overflow.
Fix by using Checked<u32> for fd counters and validating the queue
isn't empty before dequeuing acknowledged FDs.
A malicious peer could send a message declaring an IPC::File parameter
without actually including the file descriptor. This would cause
Queue::dequeue() to crash via VERIFY(!is_empty()).
Use try_dequeue() instead, which returns an error that propagates up
through the decode chain, ultimately disconnecting the misbehaving peer.
A misbehaving or malicious IPC peer could send data that triggers
crashes during message decoding:
- A Vector size that would overflow when multiplied by element size
- An out-of-bounds Variant index
Instead of using VERIFY (which crashes), return errors that propagate
up through the decode chain. This causes try_parse_message() to return
nullptr, triggering graceful peer disconnection.
A misbehaving or compromised IPC peer (e.g. a WebContent process running
malicious JavaScript) could previously crash the UI process by sending
malformed messages. This was a problem: untrusted peers should only be
able to kill their own connection, not crash the process handling them.
Replace VERIFY_NOT_REACHED() and VERIFY() calls in error paths with
graceful disconnection using the existing shutdown infrastructure
(m_peer_eof, IOThreadState::Stopped, ShouldShutdown::Yes, etc.)
Affected error paths:
- Malformed IPC messages that fail to parse
- poll() errors and POLLERR/POLLNVAL conditions
- Unexpected send/receive errors on the socket
- Invalid message header types
- Protocol violations (e.g. bad FileDescriptorAcknowledgement)
All error paths now log via dbgln() for debugging before disconnecting.
The wakeup pipe is created with O_NONBLOCK, but MUST() was used for
reads. This could cause crashes on spurious wakeups when EAGAIN is
returned. Since the read is just to drain the pipe and wake the IO
thread, we can safely ignore any errors.
The same-origin domain check always returned true if only the scheme
matched. This was because of missing steps to check for the origin's
domain, which didn't exist. Add this concept to URL::Origin, even
though we do not use it at this stage in document.domain setter.
Co-Authored-By: Luke Wilde <luke@ladybird.org>
This commit adds a missing include to MessageWindows after header
cleanup. It also implement IPC::File which had its implementation moved
out of the header, without the matching change to the windows
implementation.
Previously, TransportSocket sent queued messages from a separate thread
but performed all reading on the main thread. With this change, both
reading and writing are handled on the same I/O thread. This would allow
us to read IPC messages even while the main thread is blocked and
process them on a different thread (e.g., a rendering thread).
- Return `PeerEOF` enum instead of `Error` containing string from
`drain_messages_from_peer()`. There are no other error types to return
from this function, so boolean-like enum is sufficient.
- Don't override read hook in `ConnectionFromClient` constructor. It was
previously redefined only to suppress EOF error returned by
`drain_messages_from_peer()`.
If the Ladybird process crashes or just ends normally, the IPC transport
connection with WebContent may be shutdown after a send sync event (for
example: WebContentClient DidRequestCookie) was sent from WebContent,
but before the Ladybird process provided the matching sync event
response (for example: WebContentClient DidRequestCookieResponse). This
can lead to a runaway WebContent process if other IPC events (for
example: WebContentServer DidPaint, or SetSystemVisibilityState, or
MouseEvent, or CloseServer, etc...) are also queued when the IPC
connection is shutdown.
At the core of the issue is that the loop waiting for the matching
send sync response will prioritize waiting for the response and remain
spinning even if the IPC connection is reporting that it was shutdown,
but only if there happens to be other unrelated events received before
the IPC shutdown is detected. These unrelated events will not be
processed because the loop is stuck waiting for the response that due
to the Ladybird process having stopped, will never be sent.
Because the shutdown of the IPC connection is not handled when other
events happen to be also present, new events may be posted for transfer
by the WebContent process if the page is very active. If many new events
are posted this could lead to a slow or very quick memory leak in the
WebContent process due to the queue growing large, sometimes all the way
to total system memory exhaustion. If no events or only a few new events
are sent, then the leak may be hard to detect.
This PR fixes the faulty IPC shutdown handling by not getting stuck if
any messages are present in the receive queue. Before returning to the
caller any remaining messages will be immediately processed.
This required some changes in LibURL & LibIPC since it has its own
definition of an BlobURLEntry. For now, we don't have a concrete usage
of MediaSource in LibURL so it is defined as an empty struct.
This removes one FIXME in an idl file.
The local handling of some messages might cause the transport to get
closed. If that's the case, we shouldn't try to send back a response.
This fixes many of the "Trying to post_message during IPC shutdown"
errors I was seeing when terminating Ladybird or when abnormally exiting
from LibWeb tests.
