Kernel panic on Fedora Rawhide kernel > 6.1.0-0.rc0.20221009gita6afa4199d3d.7.fc38.x86_64

[ERLindeman]

After installing 6.1.0-0.rc0.20221014, and with every subsequent release (tested up to rc1.20221018) system fails to boot following a kernel panic. Unfortunately, due to the nature of a kernel panic, my only log documentation is photos (attached below), but both show that loading the opensnitch service appears to be causing the panic. Any help or advice would be greatly appreciated, as I rely on opensnitch in fedora deployment on my personal daily driver.

Yes, I know it's my fault for running rawhide on a production machine, but I have backup kernels to use for the time being, and upstream flows downstream eventually, so I apologize for the extra-early warning.

[gustavo-iniguez-goya]

Hi @ERLindeman ,

Could you boot up with another kernel , and obtain the kernel panic? It should have been logged to the journal: $ sudo journalctl -ar > journalctl.txt

If you boot up with another kernel, or enter into rescue-mode, try renaming the ebpf modules:

$ sudo mv /etc/opensnitchd/opensnitch.o  /etc/opensnitchd/opensnitch.o.bak
$ sudo mv /etc/opensnitchd/opensnitch-dns.o  /etc/opensnitchd/opensnitch-dns.o.bak
$ sudo mv /etc/opensnitchd/opensnitch.o  /etc/opensnitchd/opensnitch-procs.o.bak

Or set ProcMonitorMethod to proc in /etc/opensnitchd/default-config.json

[ERLindeman]

I'll share the log once I can be more certain that opensnitch is the source of the panic. I'm much less convinced of that fact now than when I opened the issue. When renaming the modules, I found that only opensnitch.o existed, and neither of the other two. Could that help point to a root cause?

[gustavo-iniguez-goya]

If you only have opensnitch.o then I guess you're using opensnitch version 1.5.x, so no problem. Rename it (or set ProcMonitorMethod to "proc" instead of "ebpf") and boot up with that kernel again.

As far as I can tell, we could cause some OOPS (it already happened #732), but not because we do something wrong (we surely do), but because there's a bug on that particular kernel. The eBPF virtual machine isolates the eBPF programs from the rest of the kernel, so they cannot compromise the stability of the system. But I guess that as this technology is being actively developed, from time to time there're bugs in newer kernels.