af_unix info comes out as af_unspec

[OriGlassman]

Description

Seems the helper 'save_sockaddr_to_buf'
doesn't include this code fix, which results in af_unix becoming af_unspec:

Output of tracee version:

(paste your output here)

Output of uname -a:

(paste your output here)

Additional details

[geyslan]

Going to run some tests on a 5.13 aarch64.

[geyslan]

@OriGlassman I wasn't able to reproduce it by doing the following - if you have a reproducer, please share with us.

Tracee

sudo ./dist/tracee -s comm=nc -e accept4

accept4 with AF_UNIX trigger

I've used accept4 since it make use of save_sockaddr_to_buf. It worth to mention that save_sockaddr_to_buf calls get_unix_sock_addr which already takes care of the struct sockaddr_un size. It's compiling and running without errors in all matrix supported kernels.

nc -Ul /tmp/sock
nc -U /tmp/sock

Perhaps the workaround mentioned in the issue above and in the #1129 isn't required any more for the supported kernels (and llvm version used).

Results

aarch64

uname -a
Linux ip-172-31-22-65 5.13.0-52-generic #59~20.04.1-Ubuntu SMP Fri Jun 17 21:11:05 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

sudo ./dist/tracee -s comm=nc -e accept4
TIME             UID    COMM             PID     TID     RET              EVENT                     ARGS
13:26:39:049537  1000   nc               8290    8290    4                accept4                   sockfd: 3, addr: map[sa_family:AF_UNIX sun_path:], addrlen: 0xffffc74a40e4, flags: 2048

{"timestamp":1735830313411340719,"threadStartTime":1735830313410305376,"processorId":0,"processId":7575,"cgroupId":1,"threadId":7575,"parentProcessId":1569,"hostProcessId":7575,"hostThreadId":7575,"hostParentProcessId":1569,"userId":1000,"mountNamespace":4026531840,"pidNamespace":4026531836,"processName":"nc","executable":{"path":""},"hostName":"ip-172-31-33-25","containerId":"","container":{},"kubernetes":{},"eventId":"242","eventName":"accept4","matchedPolicies":[""],"argsNum":4,"returnValue":4,"syscall":"accept4","stackAddresses":null,"contextFlags":{"containerStarted":false,"isCompat":false},"threadEntityId":3377640804,"processEntityId":3377640804,"parentEntityId":2556236590,"args":[{"name":"sockfd","type":"int","value":3},{"name":"addr","type":"struct sockaddr*","value":{"sa_family":"AF_UNIX","sun_path":""}},{"name":"addrlen","type":"int*","value":281474041257268},{"name":"flags","type":"int","value":2048}]}

strace nc -Ul /tmp/sock
accept4(3, {sa_family=AF_UNIX}, [128->2], SOCK_NONBLOCK) = 4

x86_64

uname -a
Linux ip-172-31-12-137 5.13.0-52-generic #59~20.04.1-Ubuntu SMP Thu Jun 16 21:21:28 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

sudo ./dist/tracee -s comm=nc -e accept4
TIME             UID    COMM             PID     TID     RET              EVENT                     ARGS
13:36:31:719160  1000   nc               7406    7406    4                accept4                   sockfd: 3, addr: map[sa_family:AF_UNIX sun_path:td], addrlen: 0x7ffdd0676364, flags: 2048


{"timestamp":1735831122265315879,"threadStartTime":1735831122264214847,"processorId":0,"processId":7183,"cgroupId":1,"threadId":7183,"parentProcessId":1920,"hostProcessId":7183,"hostThreadId":7183,"hostParentProcessId":1920,"userId":1000,"mountNamespace":4026531840,"pidNamespace":4026531836,"processName":"nc","executable":{"path":""},"hostName":"ip-172-31-9-229","containerId":"","container":{},"kubernetes":{},"eventId":"288","eventName":"accept4","matchedPolicies":[""],"argsNum":4,"returnValue":4,"syscall":"accept4","stackAddresses":null,"contextFlags":{"containerStarted":false,"isCompat":false},"threadEntityId":1134036193,"processEntityId":1134036193,"parentEntityId":2924879401,"args":[{"name":"sockfd","type":"int","value":3},{"name":"addr","type":"struct sockaddr*","value":{"sa_family":"AF_UNIX","sun_path":"td\u0004"}},{"name":"addrlen","type":"int*","value":140724937965204},{"name":"flags","type":"int","value":2048}]}

strace nc -Ul /tmp/sock
accept4(3, {sa_family=AF_UNIX}, [128->2], SOCK_NONBLOCK) = 4

--- EDIT

Updated above with json outputs as suggested by @ShohamBit. "sun_path" seems to contain garbage or malformed value "td\u0004" in this specific env (kernel 5.13 x86_64).

[ShohamBit]

Hey @geyslan did you manage to figure out the solution to this issue, as I mentioned I think this pr will probably resolve this #4442

[geyslan]

I'm gonna test this again and provide more info.