Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce use-after-free risk for UserEvents, Notifiers, etc #37

Open
jkneer opened this issue Aug 28, 2024 · 1 comment
Open

Reduce use-after-free risk for UserEvents, Notifiers, etc #37

jkneer opened this issue Aug 28, 2024 · 1 comment

Comments

@jkneer
Copy link
Contributor

jkneer commented Aug 28, 2024

Just coming back from hunting down a use-after-free bug in my code caused by UserEvents.

In summary: Some elements, i.e. notifiers, UserEvents, queues... allow the user to free the memory/reference in LabVIEW. At the same time these are things that one probably holds on for longer than just a single function call.

All I did in my code was release the UserEvent in LV right before the DLL call to my library. In the meantime my lib tried to send some UserEvents and crashed.

Idea:

  1. Test if the memory manager functions to check handles and ptrs (DSCheckHandle, DSCheckPtr) also work for the references of these elements.
  2. If that is possible we could implement a safe wrapper around the respective functionality. Maybe hidden behind a config option to disable this safety feature if the performance penalty may be unacceptable for some use cases.
@JamesMc86
Copy link
Contributor

JamesMc86 commented Sep 2, 2024

Sounds good if possible. I think we should always include the check if possible. However these use Magic Cookies instead of Handles so I expect that wouldn't work - they may be another route to look at though. Certainly a crash should be avoided at all costs.

If we cannot check it we should mark the functions as unsafe for this reason.

@github-staff github-staff deleted a comment from ViniciusSCG Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@JamesMc86 @jkneer and others