c++ – Doable leak of an IOBufferMemoryDescriptor in DriverKit driver

I’ve a DriverKit driver for iPadOS. It really works effective, however the static analyzer is flagging a potential leak that I do not perceive. The code flagged is within the driver class itself:

void IMPL(CDCDriver, ReadComplete)
{
    // Merely trampolines again to USBCDCInterface the place the learn is definitely dealt with
    IOBufferMemoryDescriptor *readDataBuffer = ivars->cdcInterface->readData(standing, actualByteCount, completionTimestamp);
    if (actualByteCount > 0) {
        os_log(OS_LOG_DEFAULT, "[Driver] Received %u bytes of information!", actualByteCount);
        if (ivars->shopper != nullptr) {
            ivars->client->dataWasReceived(readDataBuffer, actualByteCount);
        }
    }
}  // [!] Potential leak of an object saved into 'readDataBuffer'

Based on the analyzer, the decision to readData() on the primary line of the tactic returns an OSObject of sort IOBufferMemoryDescriptor with a +1 retain rely. Nonetheless, that technique is carried out like so:

IOBufferMemoryDescriptor *USBCDCInterface::readData(IOReturn standing,
                                                    uint32_t actualByteCount,
                                                    uint64_t completionTimestamp)
{
    pollForData();
    return readDataBuffer;
}

Right here, readDataBuffer is a member variable of USBCDCInterface, created when the driving force is began with a name to IOUSBHostInterface::CreateIOBuffer():

IOBufferMemoryDescriptor *readDataBuffer = nullptr;
outcome = dataInterface->CreateIOBuffer(kIOMemoryDirectionIn, 256, &readDataBuffer);
if (outcome != kIOReturnSuccess) {
    return outcome;
}
this->readDataBuffer = readDataBuffer;

My understanding of OSObject (and subclasses there of) is that it makes use of a reference counting mechanic similar to NSObject. Creating it, e.g. with CreateIOBuffer() ought to lead to an object with a +1 retain rely. The USBCDCInterface occasion that created it owns it, and due to this fact ought to launch() it when it is achieved with it (in USBCDCInterface::free()). Merely returning it from readData() should not switch possession, and it should not be the duty of the caller of that technique to launch it. Notably, calling launch() on the article on the finish of CDCDriver::ReadComplete() causes the driving force to crash, simply as I might count on, which makes me assume it is a false constructive from the analyzer.

Both my understanding is flawed, and there is one thing about returning that object from USBCDCInterface::readData() that (by conference or in any other case) obligates the caller to launch it (once more although, doing so crashes the driving force), or else it is a false constructive on the a part of the analyzer.

If this had been ObjC/Cocoa, I might guess that there is one thing concerning the naming of my strategies inflicting the analyzer to imagine the readData() technique successfully transfers possession (like a -copy or +alloc technique), however I can not discover any documentation of naming conventions like that, nor have I been capable of work out if/how OSObject strategies are annotated with their reminiscence administration semantics.

Can anybody present any perception?