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

Kernel Panic caused by netfilter #12

Closed
Leifpa opened this issue Nov 9, 2016 · 4 comments
Closed

Kernel Panic caused by netfilter #12

Leifpa opened this issue Nov 9, 2016 · 4 comments

Comments

@Leifpa
Copy link

Leifpa commented Nov 9, 2016

Hey,
I successfully installed the netfilter on a fresh installed Debian 8.6 64 Bit installation and executed the simple/create-fw.sh script, everything fine, without errors.

While the script got executed, all existing connection to my teamspeak server on the same host/ip brake.
Then, when any Teamspeak Clients tries to reconnect/connect, the whole Host keeps crashing with a kernel panic:
Nov 9 17:55:36 hostxxxx kernel: [ 2589.416468] BUG: scheduling while atomic: swapper/0/0/0x00000300 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416487] Modules linked in: xt_set xt_tcpudp iptable_raw xt_CT nf_conntrack iptable_filter ip_tables ip_set_hash_ip ip_set nfnetlink xt_ts3init(O) x_tables joydev hid_generic usbhid hid nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc x86_pkg_temp_thermal intel_powerclamp intel_rapl coretemp kvm_intel kvm crc32_pclmul iTCO_wdt iTCO_vendor_support ast evdev ttm drm_kms_helper aesni_intel drm aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd shpchp mei_me lpc_ich i2c_i801 pcspkr mei mfd_core ie31200_edac edac_core ipmi_si tpm_tis ipmi_msghandler tpm battery video button acpi_pad processor autofs4 ext4 crc16 mbcache jbd2 sg sd_mod crc_t10dif crct10dif_generic ahci libahci ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common crc32c_intel libata igb i2c_algo_bit xhci_hcd i2c_core scsi_mod dca usbcore ptp pps_core usb_common thermal fan thermal_sys Nov 9 17:55:36 hostxxxx kernel: [ 2589.416522] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.16.0-4-amd64 #1 Debian 3.16.36-1+deb8u2 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416523] Hardware name: Supermicro SYS-5038ML-H24TRF/X10SLE-DF, BIOS 2.0 04/24/2014 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416523] 0000000000000000 ffffffff815123b5 ffff88081fc03928 ffffffff8181a460 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416525] ffffffff8150f515 ffffffff81514c5d 0000000000012f40 ffffffff81803fd8 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416526] 0000000000012f40 ffffffff8181a460 ffff88081fc03928 ffff88081fc038b8 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416527] Call Trace: Nov 9 17:55:36 hostxxxx kernel: [ 2589.416528] <IRQ> [<ffffffff815123b5>] ? dump_stack+0x5d/0x78 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416535] [<ffffffff8150f515>] ? __schedule_bug+0x48/0x55 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416537] [<ffffffff81514c5d>] ? __schedule+0x5bd/0x6f0 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416539] [<ffffffff81514289>] ? schedule_timeout+0x259/0x2d0 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416541] [<ffffffff81095b65>] ? check_preempt_curr+0x75/0xa0 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416542] [<ffffffff81095ba4>] ? ttwu_do_wakeup+0x14/0xf0 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416544] [<ffffffff81515d60>] ? wait_for_completion_killable+0xc0/0x180 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416546] [<ffffffff810982e0>] ? wake_up_state+0x10/0x10 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416549] [<ffffffff8107f107>] ? call_usermodehelper_exec+0xd7/0x130 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416551] [<ffffffff8107f543>] ? __request_module+0x1b3/0x2c0 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416554] [<ffffffff8126bd35>] ? __crypto_alg_lookup+0x95/0x130 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416557] [<ffffffff8126bf2b>] ? crypto_larval_lookup+0x6b/0x170 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416558] [<ffffffff8126c04e>] ? crypto_alg_mod_lookup+0x1e/0xa0 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416560] [<ffffffff8126c151>] ? crypto_alloc_base+0x31/0xb0 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416564] [<ffffffff81424507>] ? dev_hard_start_xmit+0x2e7/0x610 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416566] [<ffffffffa02e99d7>] ? ts3init_get_cookie_seed+0x157/0x1f0 [xt_ts3init] Nov 9 17:55:36 hostxxxx kernel: [ 2589.416569] [<ffffffff814449f3>] ? sch_direct_xmit+0x63/0x1a0 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416570] [<ffffffffa02eab8e>] ? ts3init_get_current_cookie_seed+0x5e/0xb0 [xt_ts3init] Nov 9 17:55:36 hostxxxx kernel: [ 2589.416572] [<ffffffffa02ea51e>] ? ts3init_set_cookie_ipv4_tg+0x7e/0x140 [xt_ts3init] Nov 9 17:55:36 hostxxxx kernel: [ 2589.416573] [<ffffffffa02e94df>] ? ts3init_get_cookie_mt+0x3f/0x150 [xt_ts3init] Nov 9 17:55:36 hostxxxx kernel: [ 2589.416574] [<ffffffffa05888f8>] ? set_match_v3+0x88/0xf2 [xt_set] Nov 9 17:55:36 hostxxxx kernel: [ 2589.416576] [<ffffffffa0560c17>] ? ipt_do_table+0x2f7/0x710 [ip_tables] Nov 9 17:55:36 hostxxxx kernel: [ 2589.416579] [<ffffffff8149b474>] ? fib_table_lookup+0x2e4/0x390 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416581] [<ffffffff81459a30>] ? ip_rcv_finish+0x350/0x350 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416583] [<ffffffff81453385>] ? nf_iterate+0x65/0xa0 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416584] [<ffffffff81459a30>] ? ip_rcv_finish+0x350/0x350 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416586] [<ffffffff81453436>] ? nf_hook_slow+0x76/0x130 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416587] [<ffffffff81459a30>] ? ip_rcv_finish+0x350/0x350 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416588] [<ffffffff81459dbb>] ? ip_local_deliver+0x6b/0x90 Nov 9 17:55:36 hostxxxx kernel: [ 2589.416589] [<ffffffff81422873>] ? __netif_receive_skb_core+0x563/0x770

Any ideas?

Best regards
Leif

@nwerensteijn
Copy link
Contributor

breaking all existing connections when you start the example firewallscript is normal. The kernelpanic is of course not.
Does your kernel support sha512 hashes?
On my machine i can check with

$ cat /proc/crypto | grep sha512
name         : sha512
driver       : sha512-generic

@nwerensteijn
Copy link
Contributor

I looked at the trace a bit more. What I think is happening, is that we need sha512 to calculate a hash, inside a part of the kernel that should not be preemptable (and therefore can not switch contexts). We are requesting sha512 from the crypto subsystem, which apparently tries to load that module from disk. (At least that is what i make of it). And this is not allowed at this point.

I need to do a little more investigating. Perhaps we can request this module before we get to an non preemptable point. For now i think you can solve this my inserting the appropriate module (that has sha512 routines) into the kernel before you load xt_ts3init.

nwerensteijn added a commit that referenced this issue Nov 10, 2016
@nwerensteijn
Copy link
Contributor

i just commited a refactor that I hope fixes your problem. Commit bf438d0. Can you test this please?

@nwerensteijn
Copy link
Contributor

closing this issue due to lack of response. Assumed fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants