Missing "filename" argument to execve syscall in libscap 0.22.x

[ghesu11455]

Describe the bug

After changes to 0.22.x release which removed enter events being emitted by libscap for most syscalls, the filename argument for the execve syscall is now missing.

To my understanding, the procedure of removing the enter events was to add enter event arguments to the exit event, and then stop generating the enter events. This seems to have been what happened to most syscalls during the work in #2588, except for some syscalls (not including execve).

The libscap event PPME_SYSCALL_EXECVE_19_E contains the filename argument, but this was never added to the exit event PPME_SYSCALL_EXECVE_19_X. To my knowledge, there is no argument in the exit event that contains the same information. The relevant arguments I looked at was exe, comm or trusted_exepath, but they all have different information.

For us this leads to regressions, where we don't have the same information available to us after upgrading to 0.22.x

How to reproduce it

Executing the following small test program:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
    static char *args[] = { "python3", "--version", NULL };
    static char *env[] = { NULL };
    execve("/usr/bin/python3", args, env);
    perror("execve"); // will only get here on failure in execve
    exit(EXIT_FAILURE);
}

On the test system, /usr/bin/python3 is a symlink to /usr/bin/python3.13

Capturing the libscap events was done using the scap_open.c example program from the source tree, using the following command lines:

# for enter events
`./scap_open --modern_bpf --ppm_sc 324 --evt_type 292`

# for exit events
`./scap_open --modern_bpf --ppm_sc 324 --evt_type 293`

Tested version 0.22.1 and 0.20.0 or libscap. As expected, no output was generated for enter events for libscap 0.22.1. The result for the interesting arguments are summarized here:

libscap v0.22.1

Argument	Value
filename (enter)	n/a
exe	python3
comm	python3
trusted_exepath	/usr/bin/python3.13

libscap v0.20.0

Argument	Value
filename (enter)	/usr/bin/python3
exe	python3
comm	python3
trusted_exepath	/usr/bin/python3.13

We can see that the filename argument is the symlink that was executed, but this context is lost with the new version of libscap, which only provides information about the actual binary that was executed.

Expected behaviour

We expected to have the same syscall information available in the new 0.22.x version as the previous versions.

Screenshots

n/a

Environment

• Falco version:
  Only libscap, version 0.22.1 tested.
• System info:
  n/a
• Cloud provider or hardware configuration:
  n/a
• OS:

NAME="Fedora Linux"
VERSION="42 (Workstation Edition)"
RELEASE_TYPE=stable
ID=fedora
VERSION_ID=42
VERSION_CODENAME=""
PLATFORM_ID="platform:f42"
PRETTY_NAME="Fedora Linux 42 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:42"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f42/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=42
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=42
SUPPORT_END=2026-05-13
VARIANT="Workstation Edition"
VARIANT_ID=workstation

• Kernel:
  Linux fedora 6.14.9-300.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 29 14:27:53 UTC 2025 x86_64 GNU/Linux
• Installation method:
  from source

Additional context

Only libscap used, no libinsp used.

[ghesu11455]

Sorry, I messed up the tables in the description...should be fixed now

[ekoops]

Yes, you are right. Even though, from a security point of view, it is better to rely on information coming from trusted_exepath, I recognize we lost the information brought by filename, so I will address it.
Besides this I'm sure there is a similar problem for execveat.
Do you notice any other event affected by a similar issue?

Please notice that the next week Falco maintainers will be less responsive as involved in KubeCon NA (Atlanta).

/assign
/milestone 0.23.0

[ghesu11455]

Yes, it looks like execveat have similar issue with enter information that was previously available now missing. These execveat changes did not affect us, so I did not spot this until you pointed it out.

Beside this, I have not noticed any other missing arguments, although I have not examined all changed syscalls.

[ekoops]

Hey! Just for you to know that I'm working on this. I'm gonna update you soon

[ekoops]

I conducted some studies and it seems that we cannot reliably collect the filename by leveraging the current infrastructure sys_exit tracepoint + execve program/filler. Long story short: majority of times, filename is empty due to page faults or race conditions.

Luckily, we can reliably extract filename by hooking into sched/sched_process_exec tracepoint and by reading bprm->filename from there. Notice that, in some cases, we already hook into this tracepoint to generate execve exit events: #416.

The solution I'm implementing can be described as follows:

• sched/sched_process_exec is always available
  • feat(driver)!: bump drivers' minimum required kernel version to 3.10 #2722
• use sched/sched_process_exec as the only mean to generate execve exit events for successful invocations
  • feat!: default to sched_process_exec tracepoint on all architectures #2726
• add an additional filename parameter to the execve event generated by sched/sched_process_exec and execve fillers/programs
  • feat(driver): add filename parameter to PPME_SYSCALL_EXECVE_19_X #2735