Bug 212649 - ipfw(8): Referencing a table in the ruleset causes ipfw list/show to crash with SIGSEGV.
Summary: ipfw(8): Referencing a table in the ruleset causes ipfw list/show to crash wi...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.0-RC1
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-ipfw (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-13 11:24 UTC by Jan Bramkamp
Modified: 2016-11-14 14:16 UTC (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Bramkamp 2016-09-13 11:24:44 UTC 
How to reproduce:

    ipfw table foo create
    ipfw add count all from any to "table(foo)"
    ipfw list



Expected result:

A count rule is added to the IPFW rules and `ipfw list` should print all rules to stdout.



Actual result:

A count rule is added to the IPFW rules and `ipfw list` prints all rules up the first one using a table. The ipfw tool crashes in print_ip() dereferencing a NULL pointer on the first rule containing a table as destination.
Comment 1 Andrey V. Elsukov freebsd_committer freebsd_triage 2016-09-15 22:18:32 UTC 
Do you have VIMAGE in your kernel?
Comment 2 Jan Bramkamp 2016-09-16 09:52:28 UTC 
Yes but there are no vnet enabled jails running.
Comment 3 John Zielinski 2016-09-16 16:04:32 UTC 
I bet you started a vnet jail at least once since booting up.  That's what triggers it.

If you reboot and try your commands before any vnet jails start up it should work.  Start a jail and it will be back to crashing.
Comment 4 Jan Bramkamp 2016-09-16 16:34:01 UTC 
I did hit the bug in a VNET enabled jail first and suspected it to be VNET related. I was surprised to reproduce it on the host. So I stopped the VNET jail and reduced the test case as far as possible. I didn't reboot the system as I didn't expect an in-kernel data corruption. Are there regression tests for this sort of thing in FreeBSD?
Comment 5 John Zielinski 2016-09-16 18:12:36 UTC 
I'm an end user as well and hit the bug the exact same way.  First in a vnet jail and then found it in the host as well.  But I started digging through the ipfw code and then the kernel code to find out why so I could fix it and keep going with my firewall setup.

Did ipfw tables work with vnet enabled before?  If not it's not a regression.  I don't know if it worked before with vnet as I just started using vnet a few weeks ago.
Comment 6 Jan Bramkamp 2016-09-19 08:11:06 UTC 
I applied the patch from #212649 to 11.0-RC2 and it fixed the problem. Is there any chance for the patch to be included in 11.0-RELEASE?
Comment 7 Andrey V. Elsukov freebsd_committer freebsd_triage 2016-09-30 03:41:23 UTC 
Fixed in head/ and stable/11. Thanks!
Comment 8 Andrey V. Elsukov freebsd_committer freebsd_triage 2016-09-30 03:42:13 UTC 
(In reply to Jan Bramkamp from comment #6)
> I applied the patch from #212649 to 11.0-RC2 and it fixed the problem. Is
> there any chance for the patch to be included in 11.0-RELEASE?

No, it wont be in 11.0-RELEASE. Probably in some errata after release.
Comment 9 Jan Bramkamp 2016-11-14 14:16:09 UTC 
Is the errata stuck in the release engineering pipeline?