AI_ONLY_REPORT
package: cockpit-356-1.el10
------
Summary: Unbounded Fragmented WebSocket Message Growth in  
`websocketconnection.c` (Remote DoS): fragmented WebSocket messages are  
accumulated without a total-size limit before `FIN=1`, allowing remote  
memory exhaustion and service disruption in `cockpit-ws`.
Requirements to exploit: Network reachability to the `cockpit-ws` WebSocket  
endpoint and the ability to complete a valid RFC6455 handshake and stream  
many fragmented frames. The reviewed `/socket` handling suggests prior  
authentication is not strictly required when that endpoint is reachable,  
although the no-auth path initiates a graceful close rather than  
immediately tearing down I/O.
Component affected: `cockpit-356-1.el10`: `src/ws/websocketconnection.c` in  
`process_contents_rfc6455()` / `process_frame_rfc6455()`; relevant  
unauthenticated reachability is through the `/socket` handler in  
`src/ws/cockpithandlers.c`.
Version affected: `cockpit-356-1.el10`
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified separately.
CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - 7.5 (HIGH)
AV:N - The issue is reachable over the network through the `cockpit-ws`  
WebSocket endpoint.
AC:L - The attack requires only a valid WebSocket handshake and repeated  
fragmented frames below the existing per-frame limit.
PR:N - The reviewed `/socket` handling indicates prior authentication is  
not strictly required when the endpoint is reachable.
UI:N - No victim interaction is required after the service is exposed.
S:U - The impact is limited to the availability of the same `cockpit-ws`  
service that processes the frames.
C:N - No confidentiality impact is established by the available evidence.
I:N - No integrity impact is established by the available evidence.
A:H - Unbounded growth of `pv->message_data` can exhaust process memory  
and render `cockpit-ws` unavailable.
Impact: Important. Red Hat classifies flaws that allow remote users to  
cause denial of service as Important. Here, the established effect is  
remote exhaustion of `cockpit-ws` process memory and loss of service  
availability. The available evidence does not show confidentiality,  
integrity, or full system-compromise impact, so Critical would overstate  
the issue.
Embargo: no
Reason: The demonstrated impact is availability loss in `cockpit-ws`,  
not code execution or data compromise. Exposure can also be reduced  
operationally by limiting access to the WebSocket service until a fix is  
available.
Acknowledgement: Aisle Research
Vulnerability Details: `websocketconnection.c` enforces a per-frame limit  
with `MAX_PAYLOAD`, but fragmented message assembly in  
`process_contents_rfc6455()` does not impose any aggregate limit before the  
final fragment arrives:
```c
#define MAX_PAYLOAD   128 * 1024
/* Safety valve */
if (payload_len >= MAX_PAYLOAD)
{
too_big_error_and_close (self, payload_len);
return FALSE;
}
...
if (opcode)
{
pv->message_opcode = opcode;
pv->message_data = g_byte_array_sized_new (payload_len);
}
...
case 0x02:
g_byte_array_append (pv->message_data, payload, payload_len);
break;
```
Each individual frame is capped below 128 KiB, but once a fragmented  
message begins, continuation frames are appended to `pv->message_data`  
without any total message-size check. A remote peer can therefore send many  
`FIN=0` continuation frames (`opcode=0x0`) and drive unbounded heap growth  
until the `cockpit-ws` process becomes unstable or is terminated due to  
out-of-memory conditions.
The reviewed `/socket` handling accepts backward-compatible `/socket`  
requests and routes unauthenticated requests into a no-auth socket path.  
That path initiates a graceful close rather than immediately closing I/O.  
The close logic uses `close_io_after_timeout()` with a 5-second timeout,  
while normal message processing only stops after `close_received`. This  
makes unauthenticated reachability plausible where the WebSocket endpoint  
is exposed, although the amount of data accepted on a single  
unauthenticated connection still depends on timing.
Steps to reproduce:
1. Start `cockpit-ws` in a reachable configuration.
2. Complete a valid RFC6455 handshake to `/socket`.
3. Send one initial binary fragment with `FIN=0`, `opcode=0x2`, and a  
payload below 128 KiB.
4. Repeatedly send continuation fragments with `FIN=0` and `opcode=0x0`,  
each below 128 KiB.
5. Keep sending fragments without finishing the message, or finish only  
after very large accumulation.
6. Observe `cockpit-ws` resident memory growth over time as  
`pv->message_data` expands; on constrained systems this can lead to service  
disruption or OOM termination.
Mitigation: Restrict network access to the `cockpit-ws` WebSocket endpoint  
to trusted clients until a fix is available. If deployment controls allow  
it, terminate or limit long-lived fragmented WebSocket uploads before they  
reach `cockpit-ws`. Resource limits can reduce host-level impact but do not  
eliminate disruption of the affected process.
Proposed Fix: Add an aggregate fragmented-message size limit and close the  
connection with `WEB_SOCKET_CLOSE_TOO_BIG` when that limit is exceeded.
```diff
diff --git a/src/ws/websocketconnection.c b/src/ws/websocketconnection.c
index XXXXXXX..YYYYYYY 100644
— a/src/ws/websocketconnection.c
+++ b/src/ws/websocketconnection.c
@@ -145,6 +145,7 @@ typedef struct
#define MAX_PAYLOAD   128 * 1024
+#define MAX_MESSAGE   (2 * 1024 * 1024)
@@ -793,6 +794,14 @@ process_contents_rfc6455 (WebSocketConnection *self,
/* fall through */
case 0x02:
+          if (pv->message_data->len > MAX_MESSAGE - payload_len)
+            {
+              g_message ("received fragmented message larger than  
supported limit (%u bytes)",
+                         (guint) MAX_MESSAGE);
+              g_byte_array_unref (pv->message_data);
+              pv->message_data = NULL;
+              pv->message_opcode = 0;
+              too_big_error_and_close (self, MAX_MESSAGE);
+              return;
+            }
g_byte_array_append (pv->message_data, payload, payload_len);
break;
```
------
This report was generated using AI technology. Always review AI-generated  
content prior to use