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

Dropping tcp connections leads to kernel panics after nfext unloading #276

Closed
vit9696 opened this issue Jan 14, 2018 · 1 comment
Assignees
Labels
Milestone

Comments

@vit9696
Copy link

@vit9696 vit9696 commented Jan 14, 2018

Hello,

You have a bug in your kernel extension unloading, which may easily result in a kernel panic. I suppose issue #112 may be relevant, but it is more about frozen connections than the panic itself.

After rebooting the router I was unable to use any browser to load both http and https content, they simply endlessly tried to load the page. Tested in Firefox (57.0.4) and Safari (11.0.2). At the same time ping, nslookup, traceroute, vpn, and non-browser applications worked just fine, so it was soon discovered that it is an AdGuard issue.

For this reason I unloaded AdGuard and loaded it back. Afterwards I was able to browse the internet for a brief moment until I got a kernel panic.

While I cannot explain why the first bug (issues with page loading) happens, and in fact it matters less for me, I can tell why the kernel panic does.

In brief, you do not wait for all the tcp connections to close before you unload your kernel extension when clicking on the Exit button. This results in the kernel invoking your _check_connection_upcall handler at an address, which is no more mapped to your kext, since it was unloaded. The below pastes from macOS 10.13.2 panic log with symbolication make it pretty obvious:

0xffffffa3ef01b9a0 : 0xffffff801bc4fdac 0xffffff800044FDAC panic
0xffffffa3ef01ba00 : 0xffffff801bd6f2e9 0xffffff800056F2E9 kernel_trap
0xffffffa3ef01bb80 : 0xffffff801bc02120 0xffffff8000402120 trap_from_kernel
0xffffffa3ef01bba0 : 0xffffff7f9f5872f8 0x22F8       nfext _check_connection_upcall (first byte, it is unloaded already)
0xffffffa3ef01bcd0 : 0xffffff801c17ca76 0xffffff800097CA76 sodisconnectwakeup (calls to sowakeup)
0xffffffa3ef01bcf0 : 0xffffff801c015dfd 0xffffff8000815DFD tcp_close
0xffffffa3ef01bd90 : 0xffffff801c0156f5 0xffffff80008156F5 tcp_drop
0xffffffa3ef01bde0 : 0xffffff801c01a63b 0xffffff800081A63B tcp_timers
0xffffffa3ef01be50 : 0xffffff801c01b1d5 0xffffff800081B1D5 tcp_run_timerlist
0xffffffa3ef01bed0 : 0xffffff801bc89e74 0xffffff8000489E74
0xffffffa3ef01bf40 : 0xffffff801bc89965 0xffffff8000489965
0xffffffa3ef01bfa0 : 0xffffff801bc014f7 0xffffff80004014F7 call_continuation
last loaded kext at 32907541173450: com.adguard.nfext	10 (addr 0xffffff7f9f5c9000, size 180224)
last unloaded kext at 32901012462461: com.adguard.nfext	10 (addr 0xffffff7f9f585000, size 176128)

Hopefully this is fixed as soon as possible.

Best regards,
Vit

@Stillness-2 Stillness-2 added the Bug label Jan 15, 2018
@Stillness-2 Stillness-2 self-assigned this Jan 15, 2018
@ameshkov ameshkov added this to the 2.0.0 milestone Jan 15, 2018
@ameshkov ameshkov added the P3: Medium label Jan 15, 2018
@ameshkov

This comment has been minimized.

Copy link
Member

@ameshkov ameshkov commented Jan 15, 2018

Thank you for an in-depth analysis!

@Stillness-2 Stillness-2 modified the milestones: 2.0.0, 1.5.4 Mar 19, 2018
@Stillness-2 Stillness-2 modified the milestones: 1.5.4, 1.5.5 Apr 6, 2018
@zebrum zebrum closed this Apr 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.