C++ client: heap-use-after-free with long running fragment handlers (> resource linger timeout)

[StephanDollberg]

Hello,

I see the following potential heap-use-after-free:

user thread calls Subscription::poll which loads the image list:

const struct ImageList *imageList = std::atomic_load_explicit(&m_imageList, std::memory_order_acquire);

Conductor thread does a addImage or removeImage and adds the old image list (in use by the user thread) to the freelist. E.g.: from ClientConductor::onUnavailableImage

std::pair<struct ImageList *,int> result = subscription->removeImage(correlationId);

Meanwhile the user thread calls the first Image's fragment handler from Image::poll. If that fragment handler now takes longer than the resource linger timeout, the images and related resources that the user thread refers to will have been freed once the fragment handler returns. That will then probably crash in Image::poll after returning from the fragment handler when calling:

m_subscriberPosition.setOrdered(newPosition);

Let me know what you think. Coupling the correctness of the client to the time of the resource linger timeout seems off to me. Obviously, long running fragment handlers should be a rare occurrence but I don't want my program to crash if I have one on startup for example.

Thanks,
Stephan

[tmontgomery]

Yes, an interrupt that is longer than the linger timeout is a known issue in C++ as well as Java.

Less than ideal. We also know a few ways to address it and will eventually get to it. But until then, using a long enough linger is required.

[StephanDollberg]

@tmontgomery thanks for the swift reply.

Is this documented anywhere? Might be good to leave a note somewhere.

Also feel free to close this issue or keep it open if you want to keep it as a tracking ticket.

[tmontgomery]

Not sure if we've added it as a note on the javadoc or not. If so, then it might have been added to the C++ doxygen as well. Will check into that.

Let's leave this here for a little bit. I'll mark it as a question.

Thanks!