commit 4552115cc7862dcb15d731d08df694bd0551fea9
author Lucas Jenkins <lucasjenkins@google.com> Wed Jul 28 04:24:38 2021 +0000
committer releases-try-builder <releases-try-builder@fuchsia-infra.iam.gserviceaccount.com> Thu Sep 16 23:36:00 2021 +0000
tree dc66b30ac46c3da8643fbf40600bf37ee74b1d65
parent 4ec8cca853ea626af2e2ca357405bc2c625f3395

[bt][gap] Be resilient to duplicate bonds in store

In some system configuration flows, it is possible for the same
underlying bond (i.e. security information associated with a local
host address - peer address tuple) to be associated with multiple Peer
Ids, and thus added to the Store component multiple times. This can
cause issues, as bt-host fails to restore a bond if it contains an
address already associated with a different PeerId.

To be resilient to this, we check for duplicate local address-peer
address combinations when loading bonds from the store during Stash
initialization. If the underlying security information is the same, we
pick one of the bonds to store in memory and delete the duplicates from
the store. If any of the duplicate address combinations contain
distinct underlying bonds, we fail the stash initialization process, as
this indicates an invalid state in the store.

We choose to handle this at bond-loading time instead of bond-storage
time because it is not as simple to distinguish between the allowed
"replace an old bond associated with this address" flow from "add two
distinct bonds for this address" during bond storage.

Bug: b/193454286
Test: Added `new_stash_filters_duplicate_bonds` and `new_stash_fails_
      loading_same_addrs_different_bond` to `bt-gap-unittests`.
Change-Id: I0099e09c87c7fb9e92a39c2a5da513f3f7db701d
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/560662
Fuchsia-Auto-Submit: Lucas Jenkins <lucasjenkins@google.com>
Commit-Queue: Auto-Submit <auto-submit@fuchsia-infra.iam.gserviceaccount.com>
Reviewed-by: Xo Wang <xow@google.com>