You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Usually, this behavior occurs when the type of the event in the definition is signed and we cast the negative value to unsigned. I think each function should have the signature aligned with the type of the field from the event defined in the definition.
Description
I'll open an issue since I don't if the current approach is correct or not. Once we discuss it, I can submit a PR.
I was reviewing #4442 when I realized that some casting might lead to incorrect values.
The syscall
execveat
has the fieldflags
as typeint
in the definition:tracee/pkg/events/core.go
Line 8073 in 8d22a07
But here happens a cast to
uint64
before passingparseExecFlag
:tracee/pkg/events/parse_args.go
Lines 124 to 129 in 8d22a07
The issue happens when we call
execveat
usingflag=-1
. The value will be converted to0xFFFFFFFFFFFFFFFF
, setting all flags:Usually, this behavior occurs when the type of the event in the definition is signed and we cast the negative value to unsigned. I think each function should have the signature aligned with the type of the field from the event defined in the definition.
Output of
tracee version
:Output of
uname -a
:Additional details
Python code to call
execveat
withflag=-1
.The text was updated successfully, but these errors were encountered: