Skip to content

server: fix use-after-free in InitManagerImpl#6136

Closed
mergeconflict wants to merge 7 commits intoenvoyproxy:masterfrom
mergeconflict:fix_init_manager_uaf
Closed

server: fix use-after-free in InitManagerImpl#6136
mergeconflict wants to merge 7 commits intoenvoyproxy:masterfrom
mergeconflict:fix_init_manager_uaf

Conversation

@mergeconflict
Copy link
Copy Markdown

Description: Fix use-after-free where InitManagerImpl is deleted before its registered targets are finished initializing. Fixes #6116.
Risk Level: Low
Testing: Added ADS integration test which reproduces the crash without the fix.
Docs Changes: n/a
Release Notes: n/a

Dan Rosen added 2 commits February 28, 2019 18:31
Signed-off-by: Dan Rosen <mergeconflict@google.com>
Signed-off-by: Dan Rosen <mergeconflict@google.com>
Copy link
Copy Markdown
Author

@mergeconflict mergeconflict left a comment

Choose a reason for hiding this comment

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

Note to reviewers: I don't actually like this implementation, it's just the simplest, least-intrusive fix I could think of...

@htuch htuch self-assigned this Feb 28, 2019
@htuch htuch requested a review from mattklein123 February 28, 2019 23:44
Signed-off-by: Dan Rosen <mergeconflict@google.com>
Dan Rosen added 2 commits March 1, 2019 17:55
Signed-off-by: Dan Rosen <mergeconflict@google.com>
Signed-off-by: Dan Rosen <mergeconflict@google.com>
Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

Thanks for iterating on this.

I'm still not crazy about this solution and would prefer some type of handle which when destructed performs a cancellation, but I'm not going to fight for it a lot. If we keep this solution, can we add more comments in each place where canceled_ is interacted with? @lizan any thoughts here?

/wait

@lizan
Copy link
Copy Markdown
Member

lizan commented Mar 4, 2019

I'm still not crazy about this solution and would prefer some type of handle which when destructed performs a cancellation, but I'm not going to fight for it a lot.

Same here, I thought f47a376 was very close but just need a little more fix for mocks, no?

@mergeconflict
Copy link
Copy Markdown
Author

@mattklein123 @lizan - I'm actually working on a fairly different approach right now that should be more robust in all cases... It's a bigger change; I'll ping you when that's ready.

Dan Rosen added 2 commits March 5, 2019 13:07
Signed-off-by: Dan Rosen <mergeconflict@google.com>
Signed-off-by: Dan Rosen <mergeconflict@google.com>
@mergeconflict
Copy link
Copy Markdown
Author

Alright, I'm following @lizan's advice... I'm sticking with the Init::Target::cancel() approach, and I've just updated ListenerManagerImplTest to manage the lifetime of Init::Targets distinctly from the ListenerHandles they relate to.

@mattklein123
Copy link
Copy Markdown
Member

@mergeconflict can you look at CI? Those look like legit files that might be due to your change. Thank you.

/wait

@mergeconflict
Copy link
Copy Markdown
Author

@mergeconflict can you look at CI? Those look like legit files that might be due to your change. Thank you.

Yeah, I saw... I'm sure it's more breakage caused by my changes. I'll keep working on this tomorrow.

@stale
Copy link
Copy Markdown

stale bot commented Mar 13, 2019

This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Mar 13, 2019
@stale
Copy link
Copy Markdown

stale bot commented Mar 20, 2019

This pull request has been automatically closed because it has not had activity in the last 14 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@stale stale bot closed this Mar 20, 2019
htuch pushed a commit that referenced this pull request Mar 22, 2019
Introduce a new "safe" init manager, to replace the existing one that's prone to use-after-free issues (see e.g. #6116). Users of the existing init manager will be upgraded one-by-one in subsequent PRs if this design is approved. See also previous false starts in PRs #6136 and #6245.

Risk Level: Low, no existing users of the existing init manager are changed in this PR.
Testing: New unit tests added.
Docs Changes: n/a
Release Notes: n/a

Signed-off-by: Dan Rosen <mergeconflict@google.com>
@mergeconflict mergeconflict deleted the fix_init_manager_uaf branch March 27, 2019 14:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

stale stalebot believes this issue/PR has not been touched recently waiting

Projects

None yet

Development

Successfully merging this pull request may close these issues.

use-after-free in Init::Manager

4 participants