When tracing is not configured, potential null pointer dereference when accessing Tracing::Config in filters
#13,164 建立於 2020年9月17日
倉庫指標
- Star
- (27,997 star)
- PR 合併指標
- (平均合併 8天) (30 天內合併 378 個 PR)
描述
Title: When tracing is not configured, potential null pointer dereference when accessing Tracing::Config in filters
Description:
Without tracing configured, calls to Tracing::Config::operationName(), Tracing::Config::verbose(), and Tracing::Config::maxPathTagLength() via StreamFilterCallbacks::tracingConfig() lead to a null pointer dereference.
HttpConnectionManagerConfig::tracing_config_ is only initialized if tracing config is present, but ConnectionManagerImpl::ActiveStream (which implements Tracing::Config and forwards some of the calls to tracing_config_) calls methods on tracing_config_ without first performing a null check.
As far as I can tell, there isn't even a way to determine from a filter whether tracing is configured or not.
An easy solution would be to make StreamFilterCallbacks::tracingConfig() return a pointer rather than a reference so that the caller knows whether tracing is configured or not.
Repro steps:
- Create an HTTP filter that calls
tracingConfig().verbose()on a decoder callbacks instance and run it with a configuration that does not have tracing enabled.
Admin and Stats Output: N/A Config: N/A Logs: N/A Call Stack: N/A