Open elmeyer opened 7 months ago
Hi @elmeyer - Sorry for the delayed response and thanks for the detailed issue report. I've tagged this is a bug and we'll work on fixes for these.
Hi, just wanted to add that we face memory leak with sysmon on different linux OS versions (RHEL, CentOS, Debian). The amount of memory used by sysmon is increasing all the time until the service restart.
Thanks for the +1. We're working on some other issues at the moment, but we will make sure to circle back to this backlog item soon.
Hi, I would also like to add us to this problem.. We are running Sysmon version 1.3.3 on Red Hat Enterprise Linux 8.10 (Ootpa)
We experience that the memory in the system is slowly being eaten up to a point that the monitoring is alerting about high swap utilization. Sysmon consumes 7 of 8Gb swap and 1 of 3Gb RAM. A restart of the sysmon service solves the problem in the short term, after the restart sysmon is slowly consuming more and more RAM.
Hi - Thanks for following up on this! We are working on some other priority issues at the moment, but we haven't forgotten about this. Once we’ve made progress on our current priorities, we’ll revisit this issue and provide an update. In the meantime, feel free to share any additional details or context. Your input is much appreciated.
Describe the bug On multiple of our machines running Sysmon for Linux, we have noticed Sysmon for Linux occupying an ever-increasing amount of memory until the OOM killer steps in and terminates the process.
To verify that these are indeed unintended leaks, we had Sysmon for Linux run under
valgrind
over the weekend. This produced the output seen under Logs.To Reproduce We used a build of
valgrind
at commitef95220ddae1af65c85d8d59a8f0dcbb9d7af90f
(https://sourceware.org/git/?p=valgrind.git;a=commit;h=ef95220ddae1af65c85d8d59a8f0dcbb9d7af90f), since the version shipped with Debian 11 crashes when encountering unsupported eBPF commands.Sysmon version Sysmon for Linux 1.3.2, but built from source (at tag
1.3.2.0
) with-DCMAKE_CXX_FLAGS="-ggdb3"
to enhancevalgrind
output.sysmon.service
was modified to run undervalgrind
as follows (this must occur at compile time, since the service definition is linked into the Sysmon binary):This causes
sysmon -i
to hang after enabling the service, but Ctrl-Cing after that works and keeps the service running.Distro/kernel version Debian 11 "Bullseye", Kernel 6.1.0-18-amd64
Sysmon configuration
Logs
Expected behavior The main issues seem to be lack of freeing the intermediary duplicates of
tmpStringBuffer
e.g. in https://github.com/Sysinternals/SysmonCommon/blob/c1a02f4c73c81b591272ce927d8cf83f6edadf1b/eventsCommon.cpp#L2137, where the duplicate created by_tcsdup
is not freed after being duplicated again inEventDataDescCreate
(https://github.com/Sysinternals/SysmonForLinux/blob/1.3.2.0/linuxHelpers.cpp#L719). Additionally, the hash contexts created inLinuxGetFileHash
are never destroyed.