ProcessTerminate events intermittently report an unrelated user's UID instead of the terminating process's UID

Describe the bug

When reviewing PROCESS_TERMINATION (EventID 5) logs forwarded from SysmonForLinux into our SIEM, I noticed events where the User field named inactive, low-numbered system accounts (e.g. games) that had no legitimate reason to be running processes on the host. These values do not correspond to the process that actually terminated.

Having looked at the SysmonForLinux source, this appears to be caused by ProcTerminated() in ebpfKern/sysmonProcTerminated.c never zero-initializing event->m_Extensions before conditionally populating the SID extension:

ptr = (char *)(event + 1);
// no memset(event->m_Extensions, 0, sizeof(event->m_Extensions)) here —
// every other handler that emits a SID extension has one
if (task) {
    *(uint64_t *)ptr = getUid((struct task_struct*) task, config) & 0xFFFFFFFF;
    if (*(uint64_t *)ptr != 0) {
        event->m_Extensions[PT_Sid] = sizeof(uint64_t);
        ptr += sizeof(uint64_t);
    }
}

eventHdr comes from eventStorageMap, a per-CPU scratch buffer reused across every eBPF event type on that core (getEventHdr() in ebpfKern/sysmonHelpers.c). sysmonFileCreate.c, sysmonFileDelete.c, sysmonFileDeleteAt.c, sysmonFileDeleteAtCwd.c, sysmonFileOpen.c, sysmonProcAccessed.c, sysmonProcCreate.c, and sysmonBPFLoad.c all call memset(event->m_Extensions, 0, sizeof(event->m_Extensions)) before use — sysmonProcTerminated.c is the one handler that doesn't.

The practical effect: when the terminating process's UID is 0 (root), the != 0 check above skips committing the SID extension, so ptr is never advanced past the freshly-written UID bytes. eventHdr->m_EventSize — the byte count actually copied into the perf ring buffer — therefore excludes those bytes. If m_Extensions[PT_Sid] happens to still hold a stale nonzero length from earlier activity on that CPU (which it will, almost immediately after Sysmon starts, since it's never reset), userspace's ExtGetPtr()/TranslateSid() (sysmonCommon/eventsCommon.cpp) trusts that stale length, assumes the field is present, and reads 8 bytes starting immediately past the truncated event — landing on whatever unrelated data happens to sit next in the perf buffer, left over from some earlier, different event. That leftover data can resolve, via getpwuid_r, to a real but unrelated local account — which is consistent with seeing plausible-looking low-UID system accounts like games rather than obviously invalid values.

This means the bad User value should correlate specifically with processes that were actually running as root. Root-heavy, high-process-churn workloads (cloud-init and other startup-script activity on our GCP VMs, in our case) would be expected to trigger this far more frequently than steady-state activity, which matches what we're observing.

To Reproduce

Install and run SysmonForLinux with a configuration that captures ProcessTerminate events (EventID 5).
Let it run on a moderately active host — the more short-lived root-owned processes that terminate (cron jobs, startup/init scripts, systemd oneshot units, sudo invocations, etc.), the more likely the defect is to surface.
Review the User field on ProcessTerminate events. Cross-reference any event whose User looks implausible (an inactive system account, a user who shouldn't have been running that process) against other evidence of what actually ran at that PID/timestamp (auditd, shell history, ps/systemd journal for the parent).
Events where the corresponding real process is known/suspected to have run as root are the ones to focus on — non-root terminations are not affected by this particular defect.

Sysmon version

1.5.2

Distro/kernel version

Debian 12

Expected behavior

ProcessTerminate events should always report the actual UID of the process that terminated (or, per a related but distinct issue, correctly report UID 0/root — see linked issue #), never an unrelated user's UID.

Additional context

Primarily observed on GCP virtual machines with heavy/active startup scripts — which, per the root-cause analysis above, run a large number of short-lived root-owned processes and would be expected to hit this defect more often than a quieter host.