LocIpc could be using data member from a deleted obj

startListeningBlocking is meant to be called under a reader
thread, which is the case if startListeningNonBlocking calls
it. A LocIpc client may delete the LocIpc obj, which would
trigger sending an ABORT msg to the reader thread before it
is subsequently deleted, in which case, it is possible that
when the reader thread comes around to process the ABORT msg,
referencing the data members of the possibly stale obj would
cause unpredictable behaviors.

Change-Id: I441af85c04d92b6fff695c020e3e0b4bd5e90409
CRs-Fixed: 2380093

1 files changed, 1 insertions, 2 deletions

diff --git a/utils/LocIpc.h b/utils/LocIpc.h
index a1a994d..87f2ff8 100644
--- a/utils/LocIpc.h
+++ b/utils/LocIpc.h
@@ -44,7 +44,7 @@ class LocIpcSender;
 class LocIpc {
 friend LocIpcSender;
 public:
-    inline LocIpc() : mIpcFd(-1), mStopRequested(false), mRunnable(nullptr) {}
+    inline LocIpc() : mIpcFd(-1), mRunnable(nullptr) {}
     inline virtual ~LocIpc() { stopListening(); }
 
     // Listen for new messages in current thread. Calling this funciton will
@@ -93,7 +93,6 @@ private:
             const uint8_t data[], uint32_t length);
 
     int mIpcFd;
-    bool mStopRequested;
     LocThread mThread;
     LocRunnable *mRunnable;
 };