Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

named-pipes: fix receiving IOCP events after deregister #1760

Merged
merged 3 commits into from
Mar 1, 2024

Conversation

carllerche
Copy link
Member

@carllerche carllerche commented Feb 29, 2024

There is a race condition with named pipes where it is possible to receive events for a named pipe after it has been deregistered with the selector. This is because named pipes use IOCP, and there is a path where it posts a raw event, and by the time that raw event is returned by the selector the user, the user could have deregistered the I/O resource.

The fix is to post the event while maintaining the association with the I/O resource. Then, before returning the event to the user, do a final check to ensure the I/O resource (named pipe) is still registered with the selector.

Fixes #6369

@atouchet
Copy link
Contributor

atouchet commented Mar 1, 2024

That issue number doesn't exist. Typo?

@Thomasdezeeuw
Copy link
Collaborator

That issue number doesn't exist. Typo?

It's a Tokio issue, I've added a link.

Copy link
Collaborator

@Thomasdezeeuw Thomasdezeeuw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A chance that #1755 is related?

LGTM, but I've very jet lagged at the moment, so not the best reviewer. @Darksonn you want to take a look at this as well if you can?

match self.cp.as_ref().unwrap().post(completion_status) {
Ok(_) => {
// Increase the ref count of `Inner` for the completion event.
mem::forget(me.clone());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: we could use Arc::increment_strong_count, but I don't know if we use it anywhere else, if not it's ok to keep the current code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the style in the rest of the file. It probably should be updated in one go.

src/sys/windows/named_pipe.rs Show resolved Hide resolved
src/sys/windows/named_pipe.rs Show resolved Hide resolved
@Thomasdezeeuw
Copy link
Collaborator

The minimal CI seems to fail with a proper error: STATUS_STACK_BUFFER_OVERRUN: https://github.com/tokio-rs/mio/actions/runs/8103773681/job/22149086129?pr=1760#step:5:274.

@Thomasdezeeuw
Copy link
Collaborator

Oh, I just noticed this target v0.8.x branch, can you change it to master? Then we can back port afterwards, that's how we usually do it.

@carllerche carllerche changed the base branch from v0.8.x to master March 1, 2024 17:53
@carllerche
Copy link
Member Author

I rebased against master.

@carllerche
Copy link
Member Author

This issue only applies to named pipes. #1755 appears to be related to TCP, so it would not be related.

src/sys/windows/named_pipe.rs Show resolved Hide resolved
@Thomasdezeeuw Thomasdezeeuw merged commit 6fd5dd0 into master Mar 1, 2024
31 checks passed
@Thomasdezeeuw Thomasdezeeuw deleted the named-pipe-fix branch March 1, 2024 19:15
ryanfrishkorn added a commit to ryanfrishkorn/morpha that referenced this pull request Mar 4, 2024
ryanfrishkorn added a commit to ryanfrishkorn/weather-rs that referenced this pull request Mar 4, 2024
@daira
Copy link

daira commented Mar 5, 2024

For tokio users: this is marked as fixing tokio-rs/tokio#6369 but I think it should not have been: tokio-rs/tokio#6369 (comment)

@Thomasdezeeuw
Copy link
Collaborator

For Tokio users, run cargo update -p mio and you're good.

mikayla-maki pushed a commit to zed-industries/zed that referenced this pull request Mar 6, 2024
### Description
This is a part of #8809 

Update mio from 0.8.8 to 0.8.11.

When using named pipes on Windows, mio will under some circumstances
return invalid tokens that correspond to named pipes that have already
been deregistered from the mio registry. The impact of this
vulnerability depends on how mio is used. For some applications, invalid
tokens may be ignored or cause a warning or a crash. On the other hand,
for applications that store pointers in the tokens, this vulnerability
may result in a use-after-free.

### Connections

[named-pipes: fix receiving IOCP events after deregister
#1760](tokio-rs/mio#1760)

[Windows Named pipes invalid memory access
#6369](tokio-rs/tokio#6369)


Release Notes:

- N/A
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 Named pipes invalid memory access
4 participants