There exists the following race condition:
a). thread A receives setNotify and sets the callback to some object
b). thread B of the wrapped implementation calls
BiometricsFingerprint::notify which it was given a handle to. Thread B
executes past the nullptr check:
c). thread A receives setNotify and sets the callback to some other
object (or nullptr)
d). thread B resumes in notify with unknown state
Add mutex to protect access to mClientCallback.
Change-Id: I9163204ff5802e9246056caeb2a7857e6138531c
Fixes:
64802340
Test: VtsHalBiometricsFingerprintV2_1IfaceFuzzer
Return<uint64_t> BiometricsFingerprint::setNotify(
const sp<IBiometricsFingerprintClientCallback>& clientCallback) {
+ std::lock_guard<std::mutex> lock(mClientCallbackMutex);
mClientCallback = clientCallback;
// This is here because HAL 2.1 doesn't have a way to propagate a
// unique token for its driver. Subsequent versions should send a unique
void BiometricsFingerprint::notify(const fingerprint_msg_t *msg) {
BiometricsFingerprint* thisPtr = static_cast<BiometricsFingerprint*>(
BiometricsFingerprint::getInstance());
+ std::lock_guard<std::mutex> lock(thisPtr->mClientCallbackMutex);
if (thisPtr == nullptr || thisPtr->mClientCallback == nullptr) {
ALOGE("Receiving callbacks before the client callback is registered.");
return;
static FingerprintAcquiredInfo VendorAcquiredFilter(int32_t error, int32_t* vendorCode);
static BiometricsFingerprint* sInstance;
+ std::mutex mClientCallbackMutex;
sp<IBiometricsFingerprintClientCallback> mClientCallback;
fingerprint_device_t *mDevice;
};