You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 16, 2020. It is now read-only.
It's probably done in assumption that WasmState will always outlast the WasmStatePrototype it's created from
However, it's not guaranteed
The issue is reproducible on Istio 1.6.1 where use of envoy.wasm.metadata_exchange filter causes removal of WasmStatePrototype, consequent dangling pointer in WasmState and, finally, crash of Envoy
How to reproduce
The issue is consistently reproducible under the following scenario
Use Istio 1.6.1
Deploy Bookinfo application
HTTP listeners in Envoy sidecars will be configured with envoy.wasm.metadata_exchange and envoy.wasm.stats filters, namely:
the issue is caused by the dangling pointer in WasmState object
WasmStatePrototype and WasmState objects get created in envoy.wasm.metadata_exchange filter
WasmState object is being used in envoy.wasm.stats filter
envoy.wasm.stats filter gets called on a different cycle of the Envoy Dispatcher loop, which leaves a room for WasmState object to become invalid
WasmState object become invalid when WasmStatePrototype it was created from gets removed
apparently, envoy.wasm.metadata_exchange filter recreates the WasmStatePrototype object on every call to onConfigure() callback, which happens on add/update to any HTTP Listener in the sidecar
changes done as part of onConfigure() in envoy.wasm.metadata_exchange filter affect all in-inflight requests on every HTTP listener, which increases the chances that there is a WasmState object that will become invalid
The text was updated successfully, but these errors were encountered:
While troubleshooting the issue, I've prepared a patch where WasmState is re-worked to hold a std::shared_ptr<const WasmStatePrototype> instead of absl::string_view.
Let me know if you think it's a proper solution and I should open a PR.
Summary
WasmState
class usesabsl::string_view
to store some of its data (namely,schema_
)WasmState
will always outlast theWasmStatePrototype
it's created fromIstio 1.6.1
where use ofenvoy.wasm.metadata_exchange
filter causes removal ofWasmStatePrototype
, consequent dangling pointer inWasmState
and, finally, crash ofEnvoy
How to reproduce
The issue is consistently reproducible under the following scenario
Istio 1.6.1
Bookinfo
applicationEnvoy
sidecars will be configured withenvoy.wasm.metadata_exchange
andenvoy.wasm.stats
filters, namely:Product Page
Istio
configuration to cause update of aListener
inside the sidecar alongside theProduct Page
appProduct Page
app will crash withCause
WasmState
objectWasmStatePrototype
andWasmState
objects get created inenvoy.wasm.metadata_exchange
filterWasmState
object is being used inenvoy.wasm.stats
filterenvoy.wasm.stats
filter gets called on a different cycle of the Envoy Dispatcher loop, which leaves a room forWasmState
object to become invalidWasmState
object become invalid whenWasmStatePrototype
it was created from gets removedenvoy.wasm.metadata_exchange
filter recreates theWasmStatePrototype
object on every call toonConfigure()
callback, which happens on add/update to any HTTPListener
in the sidecaronConfigure()
inenvoy.wasm.metadata_exchange
filter affect all in-inflight requests on every HTTP listener, which increases the chances that there is aWasmState
object that will become invalidThe text was updated successfully, but these errors were encountered: