config_validation/server: fix initialization order redux. #6023
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Another heap-user-after-free, this time we were missing a fix that had been applied to server.h but not config_validation/server.h (envoyproxy#4940). While working on this, attempted to make fully consistent and as simple/clear as possible the constraints on member ordering. This PR is in the tradition (!) of envoyproxy#5847, envoyproxy#4940, envoyproxy#4937. I think long-term we might want to think of more dynamic and explicit declaration of ordering constraints, it's evidently pretty fragile. Also, the lack of single-source-of-truth and duplication across prod and config server code bites again. Fixes oss-fuzz issue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13228. Risk level: Low Testing: Corpus entry added. Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
source/server/server.h
Outdated
| @@ -200,6 +200,14 @@ class InstanceImpl : Logger::Loggable<Logger::Id::main>, public Instance { | |||
| void startWorkers(); | |||
| void terminate(); | |||
|
|
|||
| // init_manager_ must come before any member that participates in initialization, since | |||
There was a problem hiding this comment.
The way I read these comments, it feels like they more strongly draw attention to initialization order (top-to-bottom) rather than destruction order (bottom-to-top). I might write something like:
init_manager_ must appear before any other member that participates in initialization, so it is constructed before they reference it, and destructed only after they can no longer reference it.
... and likewise for secret_manager_.
Signed-off-by: Harvey Tuch <htuch@google.com>
mattklein123
approved these changes
Feb 21, 2019
fredlas
pushed a commit
to fredlas/envoy
that referenced
this pull request
Mar 5, 2019
…#6023) Another heap-user-after-free, this time we were missing a fix that had been applied to server.h but not config_validation/server.h (envoyproxy#4940). While working on this, attempted to make fully consistent and as simple/clear as possible the constraints on member ordering. This PR is in the tradition (!) of envoyproxy#5847, envoyproxy#4940, envoyproxy#4937. I think long-term we might want to think of more dynamic and explicit declaration of ordering constraints, it's evidently pretty fragile. Also, the lack of single-source-of-truth and duplication across prod and config server code bites again. Fixes oss-fuzz issue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13228. Risk level: Low Testing: Corpus entry added. Signed-off-by: Harvey Tuch <htuch@google.com> Signed-off-by: Fred Douglas <fredlas@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Another heap-user-after-free, this time we were missing a fix that had been applied to server.h but
not config_validation/server.h (#4940). While working on this, attempted to make fully consistent and as
simple/clear as possible the constraints on member ordering.
This PR is in the tradition (!) of #5847, #4940, #4937. I think long-term we might want to think of
more dynamic and explicit declaration of ordering constraints, it's evidently pretty fragile. Also,
the lack of single-source-of-truth and duplication across prod and config server code bites again.
Fixes oss-fuzz issue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13228.
Risk level: Low
Testing: Corpus entry added.
Signed-off-by: Harvey Tuch htuch@google.com