New issue
Advanced search Search tips
Starred by 1 user
Status: Duplicate
Merged: issue 553
Owner:
Closed: Dec 2015
Cc:



Sign in to add a comment
Spoofed no-more-senders notifications with IOBluetoothHCIPacketLogUserClient leads to unsafe parallel OSArray manipulation
Project Member Reported by ianbeer@google.com, Oct 13 2015 Back to list
The OS* data types (OSArray etc) are explicity not thread safe; they rely on their callers to implement the required locking
to serialize all accesses and manipulations of them. By sending two spoofed no-more-senders notifications on two threads at the
same time we can cause parallel calls to OSArray::removeObject with no locks which is unsafe. In this particular case you might see two threads
both passing the index >= count check in OSArray::removeObject (when count = 1 and index = 0) but then both decrementing count leading to an OSArray with
a count of 0xffffffff leading to memory corruption when trying to shift the array contents.

repro: while true; do ./iospoof_bluepacketlog; done

Tested on OS X 10.11 ElCapitan (15A284) on MacBookAir 5,2
 
iospoof_bluepacketlog.c
2.6 KB Download
Project Member Comment 1 by ianbeer@google.com, Oct 13 2015
Labels: Reported-2015-Oct-13 Id-629892139
Project Member Comment 2 by ianbeer@google.com, Dec 20 2015
Mergedinto: 553
Status: Duplicate
Project Member Comment 3 by ianbeer@google.com, Dec 20 2015
This bug was fixed as part of the fixed for CVE-2015-7047 so dup'ing into that issue
Project Member Comment 4 by ianbeer@google.com, Jan 27 2016
Labels: -Restrict-View-Commit
Sign in to add a comment