Fix a possible system server crash
The scenario is as follows : an app registers a network callback,
then unregisters it and dies immediately after. In this scenario,
the system server will receive a notification of the binder death
and enqueue a call to handleRemoveNetworkRequest. If the callback
unregister message has been process first, this call would result
in unlinkToDeath being called twice on the same Binder, crashing.
This patch fixes the problem by using handleReleaseNetworkRequest
instead of Remove, which looks up the NRI in a map on the handler
thread before calling Remove, returning without doing anything if
the NRI has already been removed.
Test: ConnectivityServiceTest
Test: New test for this
Bug: 194394697
Change-Id: I82a28c37450146838410bf5a059aac295a985fca
diff --git a/service/src/com/android/server/ConnectivityService.java b/service/src/com/android/server/ConnectivityService.java
index 770aa8a..21c5abd 100644
--- a/service/src/com/android/server/ConnectivityService.java
+++ b/service/src/com/android/server/ConnectivityService.java
@@ -5909,7 +5909,13 @@
public void binderDied() {
log("ConnectivityService NetworkRequestInfo binderDied(" +
"uid/pid:" + mUid + "/" + mPid + ", " + mBinder + ")");
- mHandler.post(() -> handleRemoveNetworkRequest(this));
+ // As an immutable collection, mRequests cannot change by the time the
+ // lambda is evaluated on the handler thread so calling .get() from a binder thread
+ // is acceptable. Use handleReleaseNetworkRequest and not directly
+ // handleRemoveNetworkRequest so as to force a lookup in the requests map, in case
+ // the app already unregistered the request.
+ mHandler.post(() -> handleReleaseNetworkRequest(mRequests.get(0),
+ mUid, false /* callOnUnavailable */));
}
@Override