Skip to content

fix(io): memory_mapped_file is move-only - #2

Closed
jeandet wants to merge 1 commit into
mainfrom
fix/mmap-file-move
Closed

jeandet wants to merge 1 commit into
mainfrom
fix/mmap-file-move

Conversation

@jeandet

@jeandet jeandet commented Nov 5, 2026

Copy link
Copy Markdown
Owner

memory_mapped_file had no move constructor but kept the implicit copy constructor.
A copy or a move left two objects owning the same mapping, and both unmapped it on destruction (the survivor then read freed memory).

CDFpp was safe only because it always holds the mapping through a shared_ptr. CEFast hit it when storing the mapping in a std::variant.

  • copy constructor/assignment deleted
  • move constructor/assignment added; a moved-from object owns nothing (POSIX fd/pointer and Windows handles)
  • move assignment releases the previous mapping first

Tests: compile-time traits (not copyable, movable) and two runtime cases (move then destroy the source first; move-assign over an existing mapping). Red before the fix, 38/38 after.

🤖 Generated with Claude Code

Copying a mapping copied the file descriptor and the address range (or the Windows
handles), so both copies unmapped the same range on destruction: a double munmap with a
use-after-free for whoever read through the surviving copy. Copies are now deleted and a
move transfers ownership, leaving the moved-from object owning nothing (destructor no-op).
Move assignment releases the previous mapping first.

Co-Authored-By: OpenCode <noreply@opencode.ai>
@jeandet

jeandet commented Nov 5, 2026

Copy link
Copy Markdown
Owner Author

Pushed directly to main instead.

@jeandet jeandet closed this Nov 5, 2026
@jeandet
jeandet deleted the fix/mmap-file-move branch November 5, 2026 22:30
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.

1 participant