FIX: NULL dereference in control_write via control-notify

[Edwin Shao]

Hello,

I’m hitting a server crash (SIGSEGV) on tmux next-3.7 (31d77e29) when control_notify_paste_buffer_deleted() calls control_write() on a client whose control_state has not yet been initialized.

Environment$ uname -sp && tmux -V && echo $TERM Darwin i386 tmux next-3.7 screen-256color

• Platform: macOS 26.3 (Build 25D125), Intel x86_64
• tmux built from master at commit 31d77e29
• $TERM outside tmux: xterm-256color
• $TERM inside tmux: screen-256color

Crash details

SIGSEGV at address 0x0000000000000020 (NULL + 32 byte struct offset).
3 crashes in a single day, all identical backtrace:

control_write +142 control_notify_paste_buffer_deleted +61 notify_callback +481 cmdq_next +492 server_loop +41 proc_loop +54

macOS crash report excerpt:

"exception": { "type": "EXC_BAD_ACCESS", "signal": "SIGSEGV", "subtype": "KERN_INVALID_ADDRESS at 0x0000000000000020" } Root cause

CONTROL_SHOULD_NOTIFY_CLIENT(c) checks (c)->flags & CLIENT_CONTROL but does not check (c)->control_state != NULL. There is a window between MSG_IDENTIFY_FLAGS (which sets CLIENT_CONTROL) and MSG_IDENTIFY_DONE (which calls control_start() to allocate control_state) where a notification can fire and hit the uninitialized pointer.

Additionally, control_stop() frees control_state but never NULLs the pointer, leaving a dangling reference during teardown.

Steps to reproduce

1. Start tmux server
2. Attach 10+ concurrent control-mode clients (tmux -C attach)
3. Rapidly execute paste-buffer -p -d -b <name> from other clients
4. Server crashes when %paste-buffer-deleted notification iterates clients
   and hits one that is mid-identification

In our case, a tmux-based agent orchestration system maintains ~12 persistent control-mode connections (one per session) and E2E tests send multiline text via load-buffer + paste-buffer -p -d at high frequency.

Patch

Attached: 0001-Fix-NULL-dereference-in-control_write-when-control_s.patch

Three changes:

1. Add control_state NULL check to CONTROL_SHOULD_NOTIFY_CLIENT macro
2. Add defensive NULL guard at top of control_write() itself (catches callers outside the notification path) (optional)
3. NULL out control_state in control_stop() after free() (prevents dangling pointer during teardown) (optional)

I agree to make this contribution under tmux’s current license.

Server logs

tmux was running with -v. The last lines of the server log before the crash show successful %paste-buffer-deleted notifications to 12 control clients, then the crash on the next client in the iteration:

notify_add: hook=paste-buffer-deleted control_vwrite: client-8070: writing line: %paste-buffer-deleted tt-1775900157427 control_vwrite: client-8082: writing line: %paste-buffer-deleted tt-1775900157427 ... control_vwrite: client-9270: writing line: %paste-buffer-deleted tt-1775900157427

Server log (4.1GB, verbose) and core dump (6.9GB) available if needed.

Best,
Edwin

[Nicholas Marriott]

Thanks, these have both been reported by others (with what looks like the same fixes) and should be fixed as soon as GitHub syncs up.

--
You received this message because you are subscribed to the Google Groups "tmux-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tmux-users+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/tmux-users/31e2f4c8-f8fa-47d6-82ff-9dc6ae99ca34n%40googlegroups.com.