Only pass the NRI for removal in NRI#binderDied
When NetworkRequestInfo#binderDied is called in ConnectivityService,
only pass the NRI to handleRemoveNetworkRequest. This is to prevent a
potential crash when unlinkDeathRecipient is called twice for the same
NRI.
Also, as a cleanup, don't iterate mRequests in the log message on binderDied.
As per the bug, the chain of events leading to a potential crash are:
- `Connectivity.NetworkRequestInfo#binderDied()` is called for an NRI
tracking multiple `NetworkRequest` items. This can happen for a TRACK_DEFAULT
request filed by a UID on a different preference than the default, which
copies the request list.
- This in turn triggers multiple `EVENT_RELEASE_NETWORK_REQUEST` events
for the same NRI, one for reach `NetworkRequest` tracked.
- When handling `EVENT_RELEASE_NETWORK_REQUEST`, each `NetworkRequest`
that is passed in will then be used to look up the parent NRI that originally
sent it to be released.
- Therefore if an NRI was tracking three requests, it would trigger three
release network events, then each request would be used to look up the
same NRI again when handling said release event.
- Finally, `ConnectivityService.NetworkRequestInfo#unlinkDeathRecipient` is
called for the NRI in question. Using the scenario above, that means we could
call `unlinkDeathRecipient` multiple times for the same NRI if it was tracking
multiple network requests causing the associated crash.
- If `unlinkDeathRecipient` is called more than once for the same NRI, it will
cause the crash listed in this bug.
- The fix is to only call handleRemoveNetworkRequest for the NRI once. This
works since when removing the NRI, we iterate over all of its requests to
remove them. By only calling handleRemoveNetworkRequest once, it's ensured
`unlinkDeathRecipient` for this NRI as part of
`Connectivity.NetworkRequestInfo#binderDied()` is only called once and not
potentially multiple times.
Bug: 185541983
Test: atest FrameworksNetTests
Change-Id: I2a2ad4ec6d415423182a1856a898779203658f8b
1 file changed
