envoyproxy/envoy

When tracing is not configured, potential null pointer dereference when accessing Tracing::Config in filters

Open

#13.164 geöffnet am 17. Sept. 2020

Auf GitHub ansehen
 (2 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)C++ (5.373 Forks)batch import
area/tracingbughelp wanted

Repository-Metriken

Stars
 (27.997 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 8T) (378 gemergte PRs in 30 T)

Beschreibung

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:

  1. 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

Contributor Guide