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

Fix a leak in libdpkg when querying the deb_packages table #6892

Merged
merged 1 commit into from
Jan 10, 2021

Conversation

Smjert
Copy link
Member

@Smjert Smjert commented Jan 10, 2021

libdpkg is leaking memory on every initialization.
Initialization happens everytime deb_packages gets queried.

The memory leaked is allocated for the "triggersdir"
global variable by "dpkg_db_get_path" called in "trigdef_update_start".
"trigdef_update_start" is called by "trig_incorporate" just after
the memory for "triggersdir" has been allocated.
In some occasions "trigdef_update_start" is also called two times in a
row. In all these cases the memory do not get deallocated in between calls,
so the old memory is lost.

Since the result of "dpkg_db_get_path" depends on the database dir that
has been set, and in the "trigdef_update_start" function it's not possible
to know if it has changed from the previous allocation or not,
it's necessary to always deallocate vs just avoid to call "dpkg_db_get_path".

Fix also a couple of other leaks on error.

Fixes: #6327

This was often hit by oss-fuzz too, though the stack trace would only contain 2 frames, vasprintf and the memory allocation.

libdpkg is leaking memory on every initialization.
Initialization happens everytime deb_packages gets queried.

The memory leaked is allocated for the "triggersdir"
global variable by "dpkg_db_get_path" called in "trigdef_update_start".
"trigdef_update_start" is called by "trig_incorporate" just after
the memory for "triggersdir" has been allocated.
In some occasions "trigdef_update_start" is also called two times in a
row. In all these cases the memory do not get deallocated in between calls,
so the old memory is lost.

Since the result of "dpkg_db_get_path" depends on the database dir that
has been set, and in the "trigdef_update_start" function it's not possible
to know if it has changed from the previous allocation or not,
it's necessary to always deallocate vs just avoid to call "dpkg_db_get_path".

Fix also a couple of other leaks on error.
@Smjert Smjert added memory leak libraries For things referring to osquery third party libraries labels Jan 10, 2021
@theopolis theopolis merged commit 8cc6d99 into osquery:master Jan 10, 2021
@Smjert Smjert deleted the stefano/libraries/leak-dpkg branch June 21, 2021 09:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libraries For things referring to osquery third party libraries memory leak
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix memory leak in vasprintf after querying deb_packages table
2 participants