Possible `Nan::Callback` leak in `inquireSync()` (two callbacks per call)

[OvOhao]

Possible Nan::Callback leak in inquireSync() (two callbacks per call)

I found a possible native heap leak in inquireSync(). Both Nan::Callbacks are
heap-allocated, used synchronously, and the method returns without deleting either.

File: src/linux/DeviceINQ.cc

Function: DeviceINQ::InquireSync

NAN_METHOD(DeviceINQ::InquireSync) {
    ...
    Nan::Callback *found = new Nan::Callback(info[0].As<Function>());
    Nan::Callback *callback = new Nan::Callback(info[1].As<Function>());
    bt_inquiry inquiryResult = DeviceINQ::doInquire();
    for (int i = 0; i < inquiryResult.num_rsp; i++) { ... found->Call(2, argv); }
    callback->Call(0, argv);
    return;                 // found and callback never deleted
}

found and callback are raw heap Nan::Callbacks (each holding a v8::Persistent to
its JS function). They are invoked synchronously and the method returns with no delete
of either, and there is no worker to own them on this synchronous path. Two
Nan::Callbacks leak on every inquireSync() call — a device-scan poll leaks two per
scan.

Suggested fix: delete found; delete callback; before returning (or hold them in owning
smart pointers).

[eelcocramer]

Thank you for contributing your findings. I will take a look at them in a few weeks when I have time.

[OvOhao]

If you could credit me as a reporter for my contributions to security advisory I will be thankful.

[eelcocramer]

How would you suggest such a credit looks like?

Also it seems that these reports where automatically generated by using genAI which is fine but should also be made transparent if this is the case.

[OvOhao]

Because I discovered this vulnerability is a common one that can appear in various forms across many repositories, I'll use GenAI to generate descriptions in bulk (since there are indeed many). I rely on my own methods and actions in both the logic and vulnerability finding.

And it looks like this

[eelcocramer]

Forgive my ignorance but where do I create such a credit report?

[OvOhao]

I'm not entirely sure either; I received the same error when reporting it in another project.

I guess you can:If you are a repository maintainer, you can add others as Reporters using the following steps:

Automatic Addition: If the vulnerability was submitted through GitHub's Private Vulnerability Reporting, GitHub will automatically add the user as the reporter and a trusted credit recipient when you accept the report.

Manual Editing Addition: Open your repository homepage and click the Security (or Security and quality) tab.

In the left sidebar, under Reporting, click Advisories. Click the Security Advisory for the person you want to add (if it's still in draft mode, click Draft; if it's published, click Edit advisory in the upper right corner).

Scroll to the Credits area at the bottom of the page. Enter the other person's GitHub username and press Enter to select it.

Select the contribution type (e.g., Reporter) from the dropdown menu next to the username. Save and update or publish the announcement (the other person will receive a confirmation notification, and their username will be publicly displayed after acceptance).