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

Failure in argument name resolution results in empty value #3892

Open
oshaked1 opened this issue Feb 22, 2024 · 2 comments
Open

Failure in argument name resolution results in empty value #3892

oshaked1 opened this issue Feb 22, 2024 · 2 comments
Labels
Milestone

Comments

@oshaked1
Copy link
Contributor

Description

When tracee tries to resolve a numeric argument to a string (e.g. cmd value of bpf syscall), if the resolution fails, the event field will contain an empty string.

For example, running the following command, which uses a new eBPF feature not supported on my kernel:

sudo bpftool gen skeleton -L hello.bpf.o > hello.skel.h

Results in the following tracee event:

TIME             UID    COMM             PID     TID     RET              EVENT                     ARGS
11:37:28:562345  0      bpftool          211739  211739  -22              bpf                       cmd: , attr: 0x7ffc011cdec0, size: 8

The strace output shows that this command is not supported, which explains why the resolution fails:

bpf(0x24 /* BPF_??? */, 0x7ffe6338f210, 8) = -1 EINVAL (Invalid argument)

This is only one example of incorrect handling of failed name resolutions, another example I found is ptrace commands, and there are possibly many others.

An example of a correctly handled name resolution is the syscall name of sys_enter, where an unknown syscall will result in the syscall number as the value.

Output of tracee version:

Tracee version: v0.20.0

Output of uname -a:

Linux ********* 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Additional details

@geyslan
Copy link
Member

geyslan commented Feb 22, 2024

@oshaked1 is this somehow related to #3891? If so, please test it again using this patch #3848.

@oshaked1
Copy link
Contributor Author

#3891 is not related though I did encounter these together. I tried your patch anyways, it doesn't seem to fix it.

@yanivagman yanivagman added this to the v0.22.0 milestone May 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants