Date: Thu, 24 May 2012 13:45:55 +0200 From: Daniel Hartmeier <daniel@benzedrine.cx> To: freebsd-ipfw@freebsd.org Subject: kern/168190: pfil hook leaving ip_len in wrong byte order (ipfw?) Message-ID: <20120524114555.GL29536@insomnia.benzedrine.cx>
next in thread | raw e-mail | index | archive | help
During the investigation of the PR panic when using pf and route-to (maybe: bad fragment handling?) http://lists.freebsd.org/pipermail/freebsd-pf/2012-May/006577.html we found that under some circumstances the ip_len in an mbuf ends up in the wrong byte order, eventually triggering an m_copym panic, variations of which were reported before (without resolution). Adding a patch to assert the correct byte order in various places http://www.benzedrine.cx/fbsd-byteorder.diff produced a panic in ipfw's pfil hook panic: ipfw_check_hook:281 ASSERT_HOST_BYTE_ORDER 45056 176 ipfw_check_hook() at ipfw_check_hook+0x511 pfil_run_hooks() at pfil_run_hooks+0xf1 ip_output() at ip_output+0x6de ip_forward() at ip_forward+0x19e ip_input() at ip_input+0x680 swi_net() at swi_net+0x15a i.e. ip_len is in host byte order during pfil_run_hooks(), which calls ipfw_check_hook(), where ip_len is converted to net byte order. Then ipfw_chk() is called (no other rules but a default allow), and back at the end of ipfw_check_hook(), ip_len is converted back to host byte order. But here the assert fails: after the conversion, ip_len is still in net byte order! I tried to find an explanation of how either ipfw_check_hook() or ipfw_chk() could possibly swap the byte order another time in between those two checks, but I couldn't find any. May I please ask an ipfw developer to take a look and review the analysis so far? Joerg Pulz might be available for further questions or patches. Thank you! Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120524114555.GL29536>