Skip to content

fix(win): use-after-free from unsynchronized access to ptyhandles#922

Merged
deepak1556 merged 1 commit into
mainfrom
robo/fix_pty_handle_access_race
May 13, 2026
Merged

fix(win): use-after-free from unsynchronized access to ptyhandles#922
deepak1556 merged 1 commit into
mainfrom
robo/fix_pty_handle_access_race

Conversation

@deepak1556
Copy link
Copy Markdown
Contributor

The windows backend keeps a global storage of ptyHandles. Since commit 17062cd that moved the ownership of the handles to the global container

  • The watcher thread called remove_pty_baton without any lock, racing with other watchers and with JS-thread reads.
  • emplace_back in startProcess could reallocate the vector while another thread was iterating it.

Fixes #921

The windows backend keeps a global vector of  `ptyHandles`.
Since the cleanup of the baton was moved into the per-pty watcher thread
(commit 17062cd):

- The watcher thread called `remove_pty_baton` without
  any lock, racing with other watchers and with JS-thread reads.
- `emplace_back` in `startProcess` could reallocate the vector while
  another thread was iterating it.
@deepak1556 deepak1556 added this to the 1.121.0 milestone May 13, 2026
@deepak1556 deepak1556 self-assigned this May 13, 2026
@deepak1556 deepak1556 enabled auto-merge (squash) May 13, 2026 11:25
@deepak1556 deepak1556 merged commit fa83ecf into main May 13, 2026
9 checks passed
@deepak1556 deepak1556 deleted the robo/fix_pty_handle_access_race branch May 13, 2026 11:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Windows ConPTY backend data race in ptyHandles can crash in remove_pty_baton

2 participants