Commit Message:
The LEDS subscription callback lambda captured used_load_assignment by value as a raw pointer to the object owned by the cluster_load_assignment_ unique_ptr. When a subsequent EDS update reassigned cluster_load_assignment_, the old object was destroyed but existing LEDS subscriptions (not recreated for unchanged configs) still held the dangling pointer. When the LEDS subscription later fired its callback (e.g. onConfigUpdateFailed), dereferencing this pointer caused a segfault.

Stack trace:

  #0: [0x77b9d6de8330]
  #1: Envoy::Upstream::EdsClusterImpl::BatchUpdateHelper::batchUpdate()
  #2: Envoy::Upstream::PrioritySetImpl::batchHostUpdate()
  #3: std::__1::__function::__func<>::operator()()
  #4: Envoy::Upstream::LedsSubscription::onConfigUpdateFailed()
  #5: Envoy::Config::GrpcSubscriptionImpl::onConfigUpdateFailed()
  #6: event_process_active_single_queue
  #7: event_base_loop
  #8: Envoy::Server::InstanceBase::run()

Fix by capturing this and accessing cluster_load_assignment_ directly, which always reflects the current valid assignment.
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

Request variables

Key	Value
ref	89e0719
sha	ee9057a
pr	43667
base-sha	5f9de99
actor	@wdauchy
message	eds: use-after-free in LEDS callback on subsequent EDS updates...
started	1772180059.808555
target-branch	main
trusted	false

Container image/s (as used in this CI run)

Envoy version (as used in this CI run)