Date: Tue, 06 Mar 2012 02:47:38 -0300 From: "Facundo M. de la Cruz" <fmdlc.unix@gmail.com> To: freebsd-hackers@freebsd.org Subject: Kernel Panic: Page fault in nat_new function (ipnat). Message-ID: <4F55A4FA.10404@gmail.com>
next in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi guys,
At my work we has a network firewall with FreeBSD 8.2-RELEASE 64 bits on
a generic box running like a network gateway (making NAT between inbound
and outbound connections). This firewall has four PCI ethernet network
cards: em0, rl0, rl1, and rl2.
The interface *em0* is configured for the WAN connection, and here is
where we're using *ipnat*. We has some map and bimap rules at
/etc/ipnat.rules file.
Repeatedly, the box crashs and the OS is reboteed writting a coredump in
/var/crash directory.
Checking the coredump file, I can see that the crash is produced by the
*fr_checknatin()* function (at
/usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c),
in the em0 interface, that then call to a trap (number 12) which becomes
fatal and then that produces a kernel panic.
Looking in the source code of ip_nat.c i can see the following (I was
researching about that :-P)
The fr_checknatin() function has two arguments:
* fin(I) -> Pointer to the packet information.
* passp(I) -> Pointer to the filtering result flag.
And the nat_new() function has five arguments:
* fin(I) -> Pointer to the packet information.
* np(I) -> Pointer to the map rule.
* natsave(I) -> Pointer to where to store the NAT struct pointer-
* flags(I) -> Flags describing the current packet.
* direction(I) -> Direction of the packet (IN/OUT).
I understand that this issue is generated by the nat_new function, that
create a new data structure for the NAT mappings without checks, and the
error is produced when the entry is duplicated.
The backtrace generated by the kernel crash is the following:
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 04
fault virtual address = 0x4
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80e25e5c
stack pointer = 0x28:0xffffff800010d630
frame pointer = 0x28:0xffffff800010d730
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (em0 taskq)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0xffffffff805f4e0e at kdb_backtrace+0x5e
#1 0xffffffff805c2d07 at panic+0x187
#2 0xffffffff808ac600 at trap_fatal+0x290
#3 0xffffffff808ac9df at trap_pfault+0x28f
#4 0xffffffff808acebf at trap+0x3df
#5 0xffffffff80894fb4 at calltrap+0x8
#6 0xffffffff80e295d2 at fr_checknatin+0x382
#7 0xffffffff80e432b3 at fr_check+0x793
#8 0xffffffff8067e35c at pfil_run_hooks+0x9c
#9 0xffffffff806d2159 at ip_input+0x279
#10 0xffffffff8067d76e at netisr_dispatch_src+0x7e
#11 0xffffffff80673b3d at ether_demux+0x14d
#12 0xffffffff80673f2d at ether_input+0x17d
#13 0xffffffff8032e50a at em_rxeof+0x1ca
#14 0xffffffff8032e928 at em_handle_que+0x48
#15 0xffffffff805ffeb5 at taskqueue_run_locked+0x85
#16 0xffffffff8060004e at taskqueue_thread_loop+0x4e
#17 0xffffffff805994f8 at fork_exit+0x118
My idea is make the minimal changes in the ipnat syntax and not to
migrate to PF, i only need to stop theses reboots, do you know any way
to fix it?. Thanks!
Regards.
- --
Facundo M. de la Cruz (tty0)
IT Consultant & Security Researcher
RHCSA/RHCE (Red Hat Certified Engineer)
GPG fingerprint: DF2F 514A 5167 00F5 C753 BF3B D797 C8E1 5726 0789
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning." -
Rich Cook
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJPVaT6AAoJENeXyOFXJgeJjDMP/3dRke43zDT5PFEodLtLIwjN
yvhVLUs3tg0FAIo9sxWH+7k/z3CxaW84jTWJ7dcqYowoS34iD58+T8qVXBl0NJ/y
FcGiXDYFJDxm6F3qSkC9VLa9bM+SWI1u7Fhp4Oj39tdC30W7WpDwoctwR/Q/ojJm
vxq7GP8CRVqIqgbHnWOgS+0QDQAyQcb6mm8GDa1Nxs49owH+EAYelhLn9S5dbBJT
1pOoftxs2Q6LixNHHZkBDRQJxoGHtPQI+lkZtFm90ODgyiGY0jmV5NmZHaXfoMUj
5s/lg+ePKemnEPL0rhxyquyqG3BBrgsCmeAGBhP1C6Z2nK4W8N+ZAVD4pX54ePbN
dEZJiLL4EvMfY06YdXepVHIPEzmbeyxo6P8KFYFD/KBwIcxUoCxTHuBzcVZ4OIZH
+Jk2HhL8rNn9LN1QeQiuw13/N6YUAP8sRfs7p/EZPRH4nX8Ng+F5CbLRUFkcOjwP
nJY7na8tZ8U2HkAKohs0gmryOHaVS6pNxtmSKRWNC0wZtBG3pWH6ANUy+FG7c2FO
E+s9C2vKT7FGVO1JE1aCuVJMs0CMXhktcxL8cPVvh6xWAdauoSa3+YO3YqevOi6T
aDpDByvfur8uVVok7jS7Vh9VpFG12ZOitv439X4tShDxxNsQLQz6jvM40MJz995U
9+eaBCK4iUuRsMfJbNOl
=BBkH
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F55A4FA.10404>