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

Incorrect network event context #4068

Open
oshaked1 opened this issue May 21, 2024 · 0 comments
Open

Incorrect network event context #4068

oshaked1 opened this issue May 21, 2024 · 0 comments
Labels

Comments

@oshaked1
Copy link
Contributor

Description

When capturing packets with tracee, multiple error messages appear:

$ sudo dist/tracee -c network -c pcap:command 2>&1 | grep error
{"level":"error","ts":1716287449.0487154,"msg":"Could not write pcap data","err":"pcaps.(*Pcaps).Write: pcaps.(*PcapCache).get: pcaps.NewPcap: pcaps.getPcapFileAndWriter: utils.OpenAt: no such file or directory"}
{"level":"error","ts":1716287449.0491126,"msg":"Could not write pcap data","err":"pcaps.(*Pcaps).Write: pcaps.(*PcapCache).get: pcaps.NewPcap: pcaps.getPcapFileAndWriter: utils.OpenAt: no such file or directory"}
{"level":"error","ts":1716287454.4983273,"msg":"Could not write pcap data","err":"pcaps.(*Pcaps).Write: pcaps.(*PcapCache).get: pcaps.NewPcap: pcaps.getPcapFileAndWriter: utils.OpenAt: no such file or directory"}
{"level":"error","ts":1716287454.4984045,"msg":"Could not write pcap data","err":"pcaps.(*Pcaps).Write: pcaps.(*PcapCache).get: pcaps.NewPcap: pcaps.getPcapFileAndWriter: utils.OpenAt: no such file or directory"}

Printing the file paths that fail to open, we see the following:

/tmp/tracee/out/pcap/commands/host/swapper/1.pcap
/tmp/tracee/out/pcap/commands/host/swapper/2.pcap
/tmp/tracee/out/pcap/commands/host/ksoftirqd/2.pcap

What happens is that the process is a kernel thread and its name contains a slash which interferes with the file path. Not checking the process names for characters that are illegal in file names is an issue, but we shouldn't be receiving packets from kernel threads regardless.

Selecting the network events which the packets are derived from, we can see there's an issue:

{"timestamp":1716282881646653150,"threadStartTime":1716281517503588090,"processorId":6,"processId":0,"cgroupId":1,"threadId":0,"parentProcessId":1,"hostProcessId":2580,"hostThreadId":2580,"hostParentProcessId":1,"userId":0,"mountNamespace":4026531841,"pidNamespace":4026531836,"processName":"swapper/6","executable":{"path":""},"hostName":"********","containerId":"","container":{},"kubernetes":{},"eventId":"2002","eventName":"net_packet_tcp",....
{"timestamp":1716282881652292135,"threadStartTime":1716281637807501839,"processorId":1,"processId":2282,"cgroupId":1,"threadId":2282,"parentProcessId":2281,"hostProcessId":2580,"hostThreadId":2580,"hostParentProcessId":2572,"userId":1000,"mountNamespace":4026532253,"pidNamespace":4026532255,"processName":"node","executable":{"path":""},"hostName":"********","containerId":"","container":{},"kubernetes":{},"eventId":"701","eventName":"net_packet_ip_base",....

We are getting a network event from the swapper/6 kernel thread, which seems to share a host PID and host TID with the node process, but the rest of the context is different.

This may be a symptom of the changes made in f806cb4 and a fix to an issue they caused in #3949.

Output of tracee version:

Tracee version: v0.21.0-rc-32-gc858afa7d

Output of uname -a:

Linux ******* 5.15.146.1-microsoft-standard-WSL2 #2 SMP Thu Apr 11 14:06:45 IDT 2024 x86_64 x86_64 x86_64 GNU/Linux
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

1 participant