When starting the opensnitch service while opensnitch-ebpf-modules is
installed, the opensnitch daemon crashes with the SIGSEGV error below.

This does not happen with the eBPF modules not installed and proc used.

I didn't provide a full backtrace because I'm not familiar with how to
get Golang programs to do a core dump nor how to get a backtrace.

   Jun 10 13:14:30 systemd[1]: Starting opensnitch.service - OpenSnitch is a GNU/Linux application firewall....
   Jun 10 13:14:30 systemd[1]: Started opensnitch.service - OpenSnitch is a GNU/Linux application firewall..
   Jun 10 13:14:30 opensnitchd[3782650]: [2023-06-10 05:14:30]  IMP  Starting opensnitch-daemon v1.5.9
   Jun 10 13:14:30 opensnitchd[3782650]: [2023-06-10 05:14:30]  INF  Loading rules from /etc/opensnitchd/rules ...
   Jun 10 13:14:30 opensnitchd[3782650]: panic: runtime error: invalid memory address or nil pointer dereference
   Jun 10 13:14:30 opensnitchd[3782650]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x5a37ac]
   Jun 10 13:14:30 opensnitchd[3782650]: goroutine 1 [running]:
   Jun 10 13:14:30 opensnitchd[3782650]: github.com/iovisor/gobpf/elf.(*Module).UpdateElement.func1(0x7f3faf601d08?, 0x0?, 0x7f3fd7c18108?, 0x10?, 0xc000058800?)
   Jun 10 13:14:30 opensnitchd[3782650]:         github.com/iovisor/gobpf/elf/table.go:75 +0x2c
   Jun 10 13:14:30 opensnitchd[3782650]: github.com/iovisor/gobpf/elf.(*Module).UpdateElement(0xc00016a000?, 0xc?, 0x97e195?, 0xa?, 0x62?)
   Jun 10 13:14:30 opensnitchd[3782650]:         github.com/iovisor/gobpf/elf/table.go:80 +0x59
   Jun 10 13:14:30 opensnitchd[3782650]: github.com/evilsocket/opensnitch/daemon/procmon/ebpf.Start()
   Jun 10 13:14:30 opensnitchd[3782650]:         github.com/evilsocket/opensnitch/daemon/procmon/ebpf/ebpf.go:95 +0x4a5
   Jun 10 13:14:30 opensnitchd[3782650]: github.com/evilsocket/opensnitch/daemon/procmon/monitor.Init()
   Jun 10 13:14:30 opensnitchd[3782650]:         github.com/evilsocket/opensnitch/daemon/procmon/monitor/init.go:55 +0x53
   Jun 10 13:14:30 opensnitchd[3782650]: github.com/evilsocket/opensnitch/daemon/procmon/monitor.ReconfigureMonitorMethod({0xc0001b26e4, 0x4})
   Jun 10 13:14:30 opensnitchd[3782650]:         github.com/evilsocket/opensnitch/daemon/procmon/monitor/init.go:29 +0x6c
   Jun 10 13:14:30 opensnitchd[3782650]: github.com/evilsocket/opensnitch/daemon/ui.(*Client).loadConfiguration(0xc0001b19e0, {0xc0004a2a00, 0x169, 0x200})
   Jun 10 13:14:30 opensnitchd[3782650]:         github.com/evilsocket/opensnitch/daemon/ui/config.go:100 +0x285
   Jun 10 13:14:30 opensnitchd[3782650]: github.com/evilsocket/opensnitch/daemon/ui.(*Client).loadDiskConfiguration(0xc0001b19e0, 0x0)
   Jun 10 13:14:30 opensnitchd[3782650]:         github.com/evilsocket/opensnitch/daemon/ui/config.go:52 +0x10a
   Jun 10 13:14:30 opensnitchd[3782650]: github.com/evilsocket/opensnitch/daemon/ui.NewClient({0x0, 0x0}, 0xc00070ea90, 0xc00011a5a0)
   Jun 10 13:14:30 opensnitchd[3782650]:         github.com/evilsocket/opensnitch/daemon/ui/client.go:82 +0x114
   Jun 10 13:14:30 opensnitchd[3782650]: main.main()
   Jun 10 13:14:30 opensnitchd[3782650]:         github.com/evilsocket/opensnitch/daemon/main.go:382 +0x62f
   Jun 10 13:14:30 systemd[1]: opensnitch.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
   Jun 10 13:14:30 systemd[1]: opensnitch.service: Failed with result 'exit-code'.

[Paul Wise 2024-06-10]

I tested a built of new upstream version 1.6.5.1 using the build rules
in experimental and a few new build dependencies (golang-github-google-uuid-dev,
golang-github-varlink-go-dev, linux-headers-amd64), and with this version there
is no segfault in the daemon.

I thus suspect this issue can be fixed by updating to the latest
upstream version, ref <URL: https://bugs.debian.org/1051317 >.

Can you test the new upstream version in experimental (or build from
the salsa git repo), and let me know if you still see this segfault?

I am running a backported edition of the experimental version using
EBPF, and do not experience any segfaults myself.

Source: opensnitch
Source-Version: 1.6.5.1-1

This was indeed fixed a long time ago in upstream version 1.6.5.1.

As the 1.6.5.1-1 version was never in Debian, BTS will understand it
better if the issue is closed with a known version.